home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 6_11_09.tro < prev    next >
Text File  |  1991-12-13  |  87KB  |  3,449 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .ce 1000
  23. APPENDIX\ II
  24. .ce 0
  25. .ce 1000
  26. (to Recommendation Q.931)
  27. .EF '%    Fascicle\ VI.11\ \(em\ Rec.\ Q.931''
  28. .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.931    %'
  29. .sp 9p
  30. .RT
  31. .ce 0
  32. .ce 1000
  33. \fBExample message flow diagrams and example\fR 
  34. .sp 1P
  35. .RT
  36. .ce 0
  37. .ce 1000
  38. \fBconditions for cause mapping\fR 
  39. .ce 0
  40. .LP
  41. II.1
  42.     \fIExample message flow diagrams\fR 
  43. .sp 1P
  44. .RT
  45. .PP
  46. Examples of the procedures for the use of the B and D channel
  47. network connection types and the selection of the appropriate channel types 
  48. are summarized in Figures II\(hy1B/FQ.931 to II\(hy7B/FQ.931. These figures 
  49. are intended to complement the description in the preceding text and do 
  50. not illustrate all 
  51. possible situations.
  52. .PP
  53. \fINote\fR \ \(em\ Not all frames that may be sent across the TA interface 
  54. may be represented in the following figures. 
  55. .RT
  56. .sp 1P
  57. .LP
  58. II.1.1
  59.     \fIKey to the figures\fR 
  60. .sp 9p
  61. .RT
  62. .LP
  63.     \fIQ.931 messages\fR 
  64. .LP
  65.     [\ ]
  66.     Layer 3
  67. .LP
  68.     C
  69.     CONNECT
  70. .LP
  71.     CA
  72.     CONNECT ACKNOWLEDGE
  73. .LP
  74.     CP
  75.     CALL PROCEEDING
  76. .LP
  77.     D
  78.     DISCONNECT
  79. .LP
  80.     R
  81.     RELEASE
  82. .LP
  83.     RC
  84.     RELEASE COMPLETE
  85. .LP
  86.     S
  87.     SETUP
  88. .PP
  89. \fIX.25 layer 3 messages\fR 
  90. .PP
  91. Any layer 3 message preceded by X.25 indicates an X.25 layer 3
  92. packet (e.g. X.25 CR means X.25 \fIcall request\fR ).
  93. .RT
  94. .LP
  95.     CA
  96.     call accepted
  97. .LP
  98.     CC
  99.     call connected
  100. .LP
  101.     CLC
  102.     clear confirmation
  103. .LP
  104.     CLI
  105.     clear indication
  106. .LP
  107.     CLR
  108.     clear request
  109. .LP
  110.     CR
  111.     call request
  112. .LP
  113.     IC
  114.     incoming call
  115. .LP
  116.     \fILayer 2 frames\fR 
  117. .LP
  118.     (\ )
  119.     Layer 2
  120. .LP
  121.     GTEI
  122.     Group TEI (127)
  123. .LP
  124.     A.B
  125.     X.25 layer 2 addresses (includes command and response)
  126. .LP
  127.     SABM
  128.     Set asynchronous balance mode
  129. .LP
  130.     SABME
  131.     Set asynchronous balance mode extended.
  132. .LP
  133.     UA
  134.     Unnumbered acknowledgement frame
  135. .LP
  136.     UI
  137.     Unnumbered information frame (i.e.\ using unacknowledged
  138. information transfer at layer\ 2)
  139. .LP
  140.     I
  141.     Information frame
  142. .LP
  143.     DISC
  144.     Disconnect frame
  145. .PP
  146. Layer 2 addresses marked (x,\ p) indicates that
  147. the\ SAPI element of the frame address is coded for packet type (SAPI\ =\ 16)
  148. information as described in Recommendation\ Q.921. Layer\ 2 addresses marked
  149. (x,\ s) refer to signalling type (SAPI\ =\ 0) information.
  150. .bp
  151. .sp 1P
  152. .LP
  153. II.1.2
  154.     \fIExample message flow diagrams\fR 
  155. .sp 9p
  156. .RT
  157. .LP
  158. .rs
  159. .sp 47P
  160. .ad r
  161. \fBFigure II\(hy1/Q.931, p.1\fR 
  162. .sp 1P
  163. .RT
  164. .ad b
  165. .RT
  166. .LP
  167. .bp
  168. .LP
  169. .rs
  170. .sp 47P
  171. .ad r
  172. \fBFigure II\(hy2/Q.931, p.2\fR 
  173. .sp 1P
  174. .RT
  175. .ad b
  176. .RT
  177. .LP
  178. .bp
  179. .LP
  180. .rs
  181. .sp 47P
  182. .ad r
  183. \fBFigure II\(hy3/Q.931, p.3\fR 
  184. .sp 1P
  185. .RT
  186. .ad b
  187. .RT
  188. .LP
  189. .bp
  190. .LP
  191. .rs
  192. .sp 47P
  193. .ad r
  194. \fBFigure II\(hy4/Q.931, p.4\fR 
  195. .sp 1P
  196. .RT
  197. .ad b
  198. .RT
  199. .LP
  200. .bp
  201. .LP
  202. .rs
  203. .sp 47P
  204. .ad r
  205. \fBFigure II\(hy5/Q.931, p.5\fR 
  206. .sp 1P
  207. .RT
  208. .ad b
  209. .RT
  210. .LP
  211. .bp
  212. .LP
  213. .rs
  214. .sp 47P
  215. .ad r
  216. \fBFigure II\(hy6/Q.931, p.6\fR 
  217. .sp 1P
  218. .RT
  219. .ad b
  220. .RT
  221. .LP
  222. .bp
  223. .LP
  224. .rs
  225. .sp 30P
  226. .ad r
  227. \fBFigure II\(hy7/Q.931, p.7\fR 
  228. .sp 1P
  229. .RT
  230. .ad b
  231. .RT
  232. .sp 1P
  233. .LP
  234. II.2
  235.     \fIExample conditions for cause mapping\fR 
  236. .sp 9p
  237. .RT
  238. .PP
  239. Figures II\(hy8/Q.931 through II\(hy16/Q.931 show example conditions when 
  240. cause mappings would be utilized between Q.931 and X.25\ [5] messages and 
  241. utilize the specific mappings of Table\ 6\(hy5/Q.931 and Table\ 6\(hy6/Q.931 
  242. as shown below: 
  243. .RT
  244. .LP
  245.     \fIFigure\fR     \fIReference Table\fR 
  246. .LP
  247.     Q.931 failures during call establishment
  248. .LP
  249.     II\(hy8
  250.     Table\ 6\(hy5/Q.931
  251. .LP
  252.     II\(hy9
  253.     Table\ 6\(hy5/Q.931
  254. .LP
  255.     II\(hy10
  256.     Table\ 6\(hy5/Q.931
  257. .LP
  258.     II\(hy11
  259.     Table\ 6\(hy5/Q.931
  260. .LP
  261.     II\(hy12
  262.     Table\ 6\(hy5/Q.931
  263. .LP
  264.     User side failures during X.25 data transfer phase
  265. .LP
  266.     II\(hy13
  267.     Table\ 6\(hy5/Q.931
  268.     \fINote\ 1\fR 
  269. .LP
  270.     II\(hy14
  271.     Table\ 6\(hy5/Q.931
  272.     \fINote\ 2\fR 
  273. .LP
  274.     Network side premature clearing
  275. .LP
  276.     II\(hy15
  277.     Table\ 6\(hy6/Q.931
  278. .LP
  279.     II\(hy16
  280.     Table\ 6\(hy6/Q.931
  281. .PP
  282. \fINote\ 1\fR \ \(em\ This mapping is only needed in the case of the Q.931
  283. message arriving prior to the clearing of the last virtual circuit.
  284. .PP
  285. \fINote\ 2\fR \ \(em\ This situation always results in either an X.25
  286. \fIclear indication\fR  | packet with cause No.\ 9, \fIout of order\fR 
  287.  | for switched 
  288. virtual circuits, or an X.25 \fIreset\fR  | packet with cause No.\ 9, \fIout 
  289. of order\fR  | for permanent virtual circuits. 
  290. .bp
  291. .RT
  292. .LP
  293. .rs
  294. .sp 13P
  295. .ad r
  296. \fBFigure II\(hy8/Q.931, p.8\fR 
  297. .sp 1P
  298. .RT
  299. .ad b
  300. .RT
  301. .LP
  302. .rs
  303. .sp 20P
  304. .ad r
  305. \fBFigure II\(hy9/Q.931, p.9\fR 
  306. .sp 1P
  307. .RT
  308. .ad b
  309. .RT
  310. .LP
  311. .rs
  312. .sp 15P
  313. .ad r
  314. \fBFigure II\(hy10/Q.931, p.10\fR 
  315. .sp 1P
  316. .RT
  317. .ad b
  318. .RT
  319. .LP
  320. .bp
  321. .LP
  322. .rs
  323. .sp 24P
  324. .ad r
  325. \fBFigure II\(hy11/Q.931, p.11\fR 
  326. .sp 1P
  327. .RT
  328. .ad b
  329. .RT
  330. .LP
  331. .rs
  332. .sp 19P
  333. .ad r
  334. \fBFigure II\(hy12/Q.931, p.12\fR 
  335. .sp 1P
  336. .RT
  337. .ad b
  338. .RT
  339. .LP
  340. .bp
  341. .LP
  342. .rs
  343. .sp 21P
  344. .ad r
  345. \fBFigure II\(hy13/Q.931, p.13\fR 
  346. .sp 1P
  347. .RT
  348. .ad b
  349. .RT
  350. .LP
  351. .rs
  352. .sp 26P
  353. .ad r
  354. \fBFigure II\(hy14/Q.931, p.14\fR 
  355. .sp 1P
  356. .RT
  357. .ad b
  358. .RT
  359. .LP
  360. .bp
  361. .LP
  362. .rs
  363. .sp 20P
  364. .ad r
  365. \fBFigure II\(hy15/Q.931, p.15\fR 
  366. .sp 1P
  367. .RT
  368. .ad b
  369. .RT
  370. .LP
  371. .rs
  372. .sp 23P
  373. .ad r
  374. \fBFigure II\(hy16/Q.931, p.16\fR 
  375. .sp 1P
  376. .RT
  377. .ad b
  378. .RT
  379. .LP
  380. .bp
  381. .ce 1000
  382. APPENDIX\ III
  383. .ce 0
  384. .ce 1000
  385. (to Recommendation Q.931)
  386. .sp 9p
  387. .RT
  388. .ce 0
  389. .ce 1000
  390. \fBSummary of assigned information element identifier and\fR 
  391. .sp 1P
  392. .RT
  393. .ce 0
  394. .ce 1000
  395. \fBmessage type code points for the Q.93x\(hySeries of Recommendations\fR 
  396. .ce 0
  397. .ce
  398. \fBH.T. [T198.931]\fR 
  399. .ce
  400. TABLE\ III\(hy1/Q.931
  401. .ce
  402. \fBInformation element code points\fR 
  403. .ps 9
  404. .vs 11
  405. .nr VS 11
  406. .nr PS 9
  407. .TS
  408. center box;
  409. lw(60p) | cw(96p) | lw(42p) .
  410.  {
  411. Bits
  412. 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1
  413.  }    Recommendation reference    
  414. _
  415. .T&
  416. lw(60p) | lw(96p) | lw(42p) .
  417.         
  418. .T&
  419. lw(198p) .
  420. .TE
  421. .nr PS 9
  422. .RT
  423. .ad r
  424. \fBTableau III\(hy1 [T198.931], p.17\fR 
  425. .sp 1P
  426. .RT
  427. .ad b
  428. .RT
  429. .LP
  430. .bp
  431. .ce
  432. \fBH.T. [T199.931]\fR 
  433. .ce
  434. TABLE\ III\(hy2/Q.931
  435. .ce
  436. \fBMessage type code points\fR 
  437. .ps 9
  438. .vs 11
  439. .nr VS 11
  440. .nr PS 9
  441. .TS
  442. center box;
  443. lw(60p) | cw(120p) | lw(48p) .
  444.  {
  445. Bits
  446. 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1
  447.  }    Recommendation reference      
  448. _
  449. .T&
  450. lw(60p) | lw(120p) | lw(48p) .
  451.         
  452. .TE
  453. .nr PS 9
  454. .RT
  455. .ad r
  456. \fBTableau III\(hy2 [T199.931], p.18\fR 
  457. .sp 1P
  458. .RT
  459. .ad b
  460. .RT
  461. .ce
  462. \fBH.T. [T200.931]\fR 
  463. .ce
  464. TABLE\ III\(hy3/Q.931
  465. .ce
  466. \fBOperation values assigned within the invoke
  467. .ce
  468. component of the facility information element\fR 
  469. .ps 9
  470. .vs 11
  471. .nr VS 11
  472. .nr PS 9
  473. .TS
  474. center box;
  475. lw(66p) | lw(114p) .
  476.  {
  477. 8\ \ 7\ \ 6\ \ 5\ \ 4\ \ 3\ \ 2\ \ 1
  478. .
  479. 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 0\ \ 1 
  480. User\(hyuser service 
  481.  }    
  482. _
  483. .TE
  484. .nr PS 9
  485. .RT
  486. .ad r
  487. \fBTableau III\(hy3 [T200.931], p.19\fR 
  488. .sp 1P
  489. .RT
  490. .ad b
  491. .RT
  492. .LP
  493. .bp
  494. .sp 1P
  495. .ce 1000
  496. \fBACRONYMS\ USED\ IN\ RECOMMENDATION\ Q.931\fR 
  497. .ce 0
  498. .sp 1P
  499. .sp 2P
  500. .LP
  501. \s8English
  502.     French
  503.     Spanish
  504. Meaning
  505. .sp 1P
  506. .RT
  507. .sp 1P
  508. .LP
  509. \s9ABM
  510.     ABM
  511.     ABM
  512.     Asynchronous Balanced Mode (of
  513. HDLC)
  514. .sp 9p
  515. .RT
  516. .LP
  517. ACK
  518.     ACK
  519.     ACU
  520.     Acknowledgement
  521. .LP
  522. ADPCM
  523.     MICDA
  524.     MICDA
  525.     Adaptative Differential Pulse Code Modulation
  526. .LP
  527. AFI
  528.     AFI
  529.     IAF
  530.     Authority and Format Identifier
  531. .LP
  532. ARM
  533.     ARM
  534.     ARM
  535.     Asynchronous Response Mode (of HDLC)
  536. .LP
  537. AU
  538.     AU
  539.     UA
  540.     Access Unit
  541. .LP
  542. BC
  543.     MFS
  544.     CP
  545.     Bearer Capability
  546. .LP
  547. BCD
  548.     BCD
  549.     DCB
  550.     Binary Coded Decimal
  551. .LP
  552. Bi
  553.     Bi
  554.     Bi
  555.     Indicated B Channel
  556. .LP
  557. Bi`
  558.     Bi`
  559.     Bi`
  560.     An idle B Channel Bi
  561. .LP
  562. Bj
  563.     Bj
  564.     Bj
  565.     A B Channel in use
  566. .LP
  567. CEI
  568.     CEI
  569.     IPEC
  570.     Connection Endpoint Identifier
  571. .LP
  572. CES
  573.     CES
  574.     SEC
  575.     Connection Endpoint Suffix
  576. .LP
  577. CSPDN
  578.     RPDCC
  579.     RPDCC
  580.     Circuit Switched Public Data Network
  581. .LP
  582. D
  583.     D
  584.     D
  585.     The D Channel
  586. .LP
  587. DDI
  588.     SDA
  589.     MDE
  590.     Direct Dialling In
  591. .LP
  592. DLCI
  593.     DLCI
  594.     ICED
  595.     Data Link Connection Identifier
  596. (See Recommendations\ Q.920/Q.921)
  597. .LP
  598. DTE
  599.     ETTD
  600.     ETD
  601.     Data Terminal Equipment
  602. .LP
  603. HDLC
  604.     HDLC
  605.     HDLC
  606.     High Level Data Link Control (procedures)
  607. .LP
  608. HLC
  609.     CCS
  610.     CCA
  611.     High Layer Compatibility
  612. .LP
  613. I
  614.     I
  615.     I
  616.     Information (frame)
  617. .LP
  618. IA5
  619.     AI5
  620.     AI5
  621.     International Alphabet No.\ 5 (defined by CCITT)
  622. .LP
  623. IE
  624.     EI
  625.     EI
  626.     Information Element
  627. .LP
  628. ISDN
  629.     RNIS
  630.     RDSI
  631.     Integrated Services Digital Network
  632. .LP
  633. ISO
  634.     ISO
  635.     ISO
  636.     International Standard Organization
  637. .LP
  638. IWF
  639.     IWF
  640.     FIF
  641.     Interworking Function
  642. .LP
  643. IWU
  644.     UIF
  645.     UIF
  646.     Interworking Unit
  647. .LP
  648. LAN
  649.     RLE
  650.     RAL
  651.     Local Area Network
  652. .LP
  653. LAPB
  654.     LAPB
  655.     LAPB
  656.     Link Access Protocol\(hyBalanced
  657. .LP
  658. LAPD
  659.     LAPD
  660.     LAPD
  661.     Link Acces Protocol on the D Channel
  662. .LP
  663. LLC
  664.     CCI
  665.     CCB
  666.     Low Layer Compatibility
  667. .LP
  668. LLI
  669.     LLI
  670.     IEL
  671.     Logical Link Identifier (See Recommendation\ Q.921)
  672. .LP
  673. NACK
  674.     NACK
  675.     ACUN
  676.     Negative Acknowledgement
  677. .LP
  678. NIC
  679.     NIC
  680.     RIR
  681.     Network Independent Clock
  682. .LP
  683. NRM
  684.     NRM
  685.     NRM
  686.     Normal Response Mode (of HDLC)
  687. .LP
  688. NSAP
  689.     NSAP
  690.     PASR
  691.     Network Service Access Point
  692. .LP
  693. NT2
  694.     NT2
  695.     TR2
  696.     Network Termination of type two
  697. .LP
  698. OSI
  699.     OSI
  700.     ISA
  701.     Open System Interconnection
  702. .LP
  703. PABX
  704.     PABX
  705.     CAP
  706.     Private Automatic Branch Exchange
  707. .LP
  708. PCM
  709.     MIC
  710.     MIC
  711.     Pulse Code Modulation
  712. .bp
  713. .LP
  714. PH
  715.     PH
  716.     MP
  717.     Packet Handler
  718. .LP
  719. PSPDN
  720.     RPDCP
  721.     RPDCP
  722.     Packet Switched Public Data Network
  723. .LP
  724. PSTN
  725.     RTPC
  726.     RTPC
  727.     Public Switched Telephony Network
  728. .LP
  729. PVC
  730.     CVP
  731.     CVP
  732.     Permanent Virtual Circuit
  733. .LP
  734. RDTD
  735.     RDTD
  736.     RDR
  737.     Restricted Differential Time Delay
  738. .LP
  739. SABME
  740.     SABME
  741.     SABME
  742.     Set Asynchronous Balanced Mode Extended (frame)
  743. .LP
  744. SAPI
  745.     SAPI
  746.     IPAS
  747.     Service Access Point Identifier (See
  748. Recommendation\ Q.921)
  749. .LP
  750. TA
  751.     AT
  752.     AT
  753.     Terminal Adaptor (See Recommendation I.411)
  754. .LP
  755. TE1
  756.     TE1
  757.     ET1
  758.     Terminal Equipment of type\ 1 (See
  759. Recommendation\ I.411)
  760. .LP
  761. TE2
  762.     TE2
  763.     ET2
  764.     Terminal Equipment of type\ 2 (See
  765. Recommendation\ I.411)
  766. .LP
  767. TEI
  768.     TEI
  769.     IET
  770.     Terminal Endpoint Identifier (See
  771. Recommendations\ Q.920 and Q.921)
  772. .LP
  773. UDI
  774.     UDI
  775.     IDSR
  776.     Unrestricted Digital Information
  777. .LP
  778. UI
  779.     UI
  780.     UI
  781.     Unnumbered Information (frame)
  782. .LP
  783. VC
  784.     CV
  785.     CV
  786.     (Switched) Virtual Circuit
  787. .sp 2P
  788. .LP
  789.     \fBReferences\fR 
  790. .sp 1P
  791. .RT
  792. .LP
  793. [1]
  794.      CCITT Recommendation \fIISDN user\(hynetwork interface layer 3 \(em General\fR 
  795. \fIaspects\fR ,  | ol.\ VI(III), Rec.\ Q.930(I.450).
  796. .LP
  797. [2]
  798.     CCITT Recommendation \fIISDN user\(hynetwork interfaces \(em Interface\fR 
  799. \fIstructures and access capabilities\fR ,  | ol.\ III, Rec.\ I.412.
  800. .LP
  801. [3]
  802.     CCITT Recommendation \fIISDN user\(hynetwork interface \(em Data link\fR 
  803. \fIlayer specification\fR ,  | ol.\ VI(III), Rec.\ Q.921(I.441).
  804. .LP
  805. [4]
  806.     CCITT Recommendation \fIGeneric procedures for the control of\fR 
  807. \fIISDN supplementary services\fR ,  | ol.\ VI, Rec.\ Q.932.
  808. .LP
  809. [5]
  810.     CCITT Recommendation \fIInterface between data terminal equipment\fR 
  811. \fI(DTE) and data circuit terminating equipment (DCE) for terminals operating 
  812. in\fR \fIthe packet mode and connected to public data networks by dedicated 
  813. circuit\fR , | Vol.\ VIII, Rec.\ X.25. 
  814. .LP
  815. [6]
  816.     CCITT Recommendation \fICircuit mode bearer service categories\fR , |
  817. Vol.\ III, Rec.\ I.231.
  818. .LP
  819. [7]
  820.     CCITT Recommendation \fISupport of data terminal equipments\fR 
  821. \fI(DTEs) with V\(hyseries type interfaces by an integrated services digital\fR 
  822. \fInetwork (ISDN)\fR , Vol.\ VIII, Rec.\ V.110.
  823. .LP
  824. [8]
  825.     CCITT Recommendation \fISupport of X.21, X.21 | is and X.20 | is\fR 
  826. \fIbased data terminal equipments (DTEs) by an integrated services digital\fR 
  827. \fInetwork (ISDN)\fR ,  | ol.\ VIII, Rec.\ X.30.
  828. .LP
  829. [9]
  830.     CCITT Recommendation \fISupport by an ISDN of data terminal equipment\fR 
  831. \fIwith V\(hyseries type interfaces with provision for statistical\fR 
  832. \fImultiplexing\fR , | Vol. VIII, Rec.\ V.120.
  833. .LP
  834. [10]
  835.     CCITT Recommendation \fIPulse code modulation (PCM) of voice\fR 
  836. \fIfrequencies\fR , | Vol.\ III, Rec.\ G.711.
  837. .LP
  838. [11]
  839.     CCITT Recommendation \fI32 kbitB/Fs adaptive differential pulse code\fR 
  840. \fImodulation (ADPCM)\fR , | Vol.\ III, Rec.\ G.721.
  841. .LP
  842. [12]
  843.      CCITT Recommendation \fI7\ kHz audio coding within 64\ kbit/s\fR , | 
  844. Vol.\ III, Rec.\ G.722. 
  845. .LP
  846. [13]
  847.     CCITT Recommendation \fICodec for audiovisual services\fR 
  848. \fIAT\ n\ \(mu\ 384\ kbit/s\fR , | Vol.\ III, Rec.\ H.261.
  849. .LP
  850. [14]
  851.     CCITT Recommendation \fISupport of packet mode terminal equipment by\fR 
  852. \fIan ISDN\fR ,  | ol.\ VIII, Rec.\ X.31.
  853. .LP
  854. [15]
  855.     CCITT Recommendation \fIMultiplexing rate adaptation and support\fR 
  856. \fIof existing interfaces\fR , | Vol.\ III, Rec.\ I.460.
  857. .bp
  858. .LP
  859. [16]
  860.     CCITT Recommendation \fIStandardization of data signalling\fR 
  861. \fIrates for synchronous data transmission on leased telephone\(hytype 
  862. circuits\fR , | Vol.\ VIII, Rec.\ V.6. 
  863. .LP
  864. [17]
  865.      CCITT Recommendation \fIInternational user classes of service in public\fR 
  866. \fIdata networks and integrated services digital networks (ISDNs)\fR , | 
  867. Vol.\ VIII, Rec.\ X.1. 
  868. .LP
  869. [18]
  870.     CCITT Recommendation \fIISDN numbering and addressing principles\fR , |
  871. Vol.\ III, Rec.\ I.330.
  872. .LP
  873. [19]
  874.     CCITT Recommendation \fINumbering plan for the ISDN era\fR , | Vol.\ II,
  875. Rec.\ E.164.
  876. .LP
  877. [20]
  878.      CCITT Recommendation \fINumbering plan for the international telephone\fR 
  879. \fIservice\fR , | Vol.\ III, Rec.\ E.163. 
  880. .LP
  881. [21]
  882.     CCITT Recommendation \fIInternational numbering plan for public data\fR 
  883. \fInetworks\fR , | Vol.\ VIII, Rec.\ X.121.
  884. .LP
  885. [22]
  886.     CCITT Recommendation \fIPlan for telex destination codes\fR , | Vol.\ II,
  887. Rec.\ F.69.
  888. .LP
  889. [23]
  890.     CCITT Recommendation \fINetwork service definition for open systems\fR 
  891. \fIinterconnection (OSI) for CCITT applications\fR , | Vol.\ VIII, Rec.\ X.213.
  892. .LP
  893. [24]
  894.      ISO Standard 8348 Addendum 2 \fIInformation processing systems \(em Data\fR 
  895. \fIcommunications \(em Network service definition\fR . 
  896. .LP
  897. [25]
  898.      CCITT Recommendation \fIPrinciples relating ISDN numbers/subaddress to\fR 
  899. \fIthe OSI reference model network layer addresses\fR , | Vol.\ III, Rec.\ 
  900. I.334. 
  901. .LP
  902. [26]
  903.     CCITT Recommendation \fIInterface between data terminal equipment\fR 
  904. \fI(DTE)\ and data circuit\(hyterminating equipment (DCE) for synchronous 
  905. operation\fR \fIon public data networks\fR , | Vol.\ VIII, Rec.\ X.21. 
  906. .LP
  907. [27]
  908.      CCITT Recommendation \fIPrimary rate user\(hynetwork interface \(em Layer\ 
  909. 1\fR \fIspecification\fR , | Vol.\ III, Rec.\ I.431. 
  910. .LP
  911. [28]
  912.     CCITT Recommendation \fIControl procedures for teletex and Group\ 4\fR 
  913. \fIfacsimile services\fR , | Vol.\ VII, Rec.\ T.62.
  914. .LP
  915. [29]
  916.     CCITT Recommendation \fIA document application profile for the\fR 
  917. \fIinterchange of Group\ 4 facsimile documents\fR , | Vol.\ VII, Rec.\ T.503.
  918. .LP
  919. [30]
  920.     CCITT Recommendation \fIA document application profile MM for the\fR 
  921. \fIinterchange of formatted mixed mode documents\fR , | Vol.\ VII, Rec.\ T.501.
  922. .LP
  923. [31]
  924.     CCITT Recommendation \fIDocument application profile PM1 for the\fR 
  925. \fIinterchange of processable form documents\fR , | Vol.\ VII, Rec.\ T.502.
  926. .LP
  927. [32]
  928.     CCITT Recommendation \fINetwork\(hyindependent basic transport service\fR 
  929. \fIfor the telematic services\fR , | Vol.\ VII, Rec.\ T.70.
  930. .LP
  931. [33]
  932.     CCITT Recommendation \fIDocument application profile for\fR 
  933. \fIvideotex interworking\fR , | Vol.\ VII, Rec.\ T.504.
  934. .LP
  935. [34]
  936.     CCITT Recommendation \fITeleservices supported by an ISDN\fR , | Vol.\ III,
  937. Rec.\ I.241.
  938. .LP
  939. [35]
  940.     CCITT Recommendation \fISystem aspects of the use of the 7\ kHz audio\fR 
  941. \fIcodec within 64\ kbit/s\fR , | Vol.\ III, Rec.\ G.725.
  942. .LP
  943. [36]
  944.     ISO Standard 1745 \fIInformation processing \(em Basic mode control\fR 
  945. \fIprocedures for data communication systems\fR .
  946. .LP
  947. [37]
  948.      CCITT Recommendation \fILink access protocol balanced (LAPB) extended\fR 
  949. \fIfor half\(hyduplex physical level facility\fR , | Vol.\ VII, Rec.\ T.71. 
  950. .LP
  951. [38]
  952.      ISO Standard 4335 \fIData communication \(em High\(hylevel data link 
  953. control\fR \fIprocedures \(em Consolidation of elements of procedures\fR 
  954. . 
  955. .LP
  956. [39]
  957.     ISO Standard 8802\(hy2 \fIInformation processing systems \(em Local area\fR 
  958. \fInetworks \(em Part\ 2: Logical link control\fR .
  959. .LP
  960. [40]
  961.     CCITT Recommendation \fIPacket switched signalling system between\fR 
  962. \fIpublic networks providing data transmission services\fR , | Vol.\ VIII, 
  963. Rec.\ X.75. 
  964. .LP
  965. [41]
  966.     ISO Standard 8208 \fIInformation processing systems \(em Data\fR 
  967. \fIcommunications \(em X.25 packet level protocol for data terminal equipment\fR 
  968. . 
  969. .bp
  970. .LP
  971. [42]
  972.     ISO Standard 8348 \fIInformation processing systems \(em Data\fR 
  973. \fIcommunications \(em Network service definition\fR .
  974. .LP
  975. [43]
  976.     ISO Standard 8473 \fIInformation processing systems \(em Data\fR 
  977. \fIcommunications protocol for providing the connectionless\(hymode network\fR 
  978. \fIservice\fR .
  979. .LP
  980. [44]
  981.     CCITT Recommendation \fIProcedure for the exchange of protocol\fR 
  982. \fIidentification during virtual call establishment on packet switched 
  983. public\fR \fIdata networks\fR , | Vol.\ VIII, Rec.\ X.244. 
  984. .LP
  985. [45]
  986.     CCITT Recommendation \fIISDN user\(hynetwork interface data link\fR 
  987. \fIlayer \(em General aspects\fR , | Vol.\ VI(III), Rec.\ Q.920(I.440).
  988. .LP
  989. [46]
  990.     CCITT Recommendation \fIBasic user\(hynetwork interface \(em Layer\ 1\fR 
  991. \fIspecification\fR , | Vol.\ III, Rec.\ I.430.
  992. .LP
  993. [47]
  994.     CCITT Recommendation \fIDefinition of bearer service categories\fR , |
  995. Vol.\ III, Rec.\ I.230.
  996. .LP
  997. [48]
  998.     CCITT Recommendation \fIDefinition of teleservices\fR , | Vol.\ III,
  999. Rec.\ I.240.
  1000. .LP
  1001. [49]
  1002.     CCITT Recommendation \fIInternational Alphabet No.\ 5\fR , | Vol.\ VII,
  1003. Rec.\ T.50.
  1004. .LP
  1005. [50]
  1006.     ISO Standard 646 \fIInformation processing \(em ISO 7\(hybit coded\fR 
  1007. \fIcharacter set for information interchange\fR .
  1008. .LP
  1009. [51]
  1010.      CCITT Recommendations on \fIIntegrated services digital network (ISDN)\fR 
  1011. , | Vol.\ III. 
  1012. .LP
  1013. [52]
  1014.     CCITT Recommendation \fISupport of data terminal equipments (DTEs)\fR 
  1015. \fIwith V\(hyseries type interfaces by an integrated services digital network\fR 
  1016. \fI(ISDN)\fR , | Vol.\ III, Rec.\ I.463.
  1017. .sp 2P
  1018. .LP
  1019. \fBRecommendation Q.932\fR 
  1020. .RT
  1021. .sp 2P
  1022. .sp 1P
  1023. .ce 1000
  1024. \fBGENERIC\ PROCEDURES\ FOR\ THE\ CONTROL\ OF\fR  |
  1025. \fBISDN\ SUPPLEMENTARY\ SERVICES\fR 
  1026. .EF '%    Fascicle\ VI.11\ \(em\ Rec.\ Q.932''
  1027. .OF '''Fascicle\ VI.11\ \(em\ Rec.\ Q.932    %'
  1028. .ce 0
  1029. .sp 1P
  1030. .LP
  1031. \fB1\fR     \fBGeneral\fR 
  1032. .sp 1P
  1033. .RT
  1034. .PP
  1035. This Recommendation defines the generic procedures applicable for the control 
  1036. of supplementary services at the user\(hynetwork interface. These 
  1037. procedures may be used for the invocation and operation of supplementary
  1038. services in association with existing calls or outside any existing calls.
  1039. .PP
  1040. The detailed procedures applicable to individual supplementary
  1041. services are outside the scope of this Recommendation. However, typical
  1042. examples of the application of these generic procedures to some supplementary 
  1043. services are provided in Appendix\ I to this Recommendation for explanatory 
  1044. and illustrative purposes only. The application of the Functional protocol 
  1045. defined in \(sc\ 6, to the operation of individual supplementary services 
  1046. will be the subject of future Recommendations in this series.
  1047. .RT
  1048. .sp 2P
  1049. .LP
  1050. \fB2\fR     \fBOverview of the generic protocols and of their scope\fR 
  1051. .sp 1P
  1052. .RT
  1053. .PP
  1054. Three generic protocols are defined for the control of
  1055. supplementary services at ISDN user\(hynetwork interfaces. These protocols 
  1056. operate at layer 3 of the control plane at the SB/FT reference points, 
  1057. and assume that 
  1058. the use of layers\ 1 and\ 2 conforms to Recommendations\ I.430 | 1], I.431 | 2] 
  1059. and Q.921 | 3]. In addition, the three generic protocols assume the existence 
  1060. of an established data link and use the acknowledged information transfer 
  1061. service 
  1062. available at the layer\ 2 to layer\ 3 interface.
  1063. .RT
  1064. .sp 1P
  1065. .LP
  1066. 2.1
  1067.     \fIThree generic protocols\fR 
  1068. .sp 9p
  1069. .RT
  1070. .PP
  1071. Three generic protocols are defined for the control of
  1072. supplementary services, two of which are stimulus, the third being functional; 
  1073. these protocols are: 
  1074. .RT
  1075. .LP
  1076.     \(em
  1077.     the Keypad protocol;
  1078. .LP
  1079.     \(em
  1080.     the Feature key management protocol;
  1081. .LP
  1082.     \(em
  1083.     the Functional protocol.
  1084. .bp
  1085. .sp 1P
  1086. .LP
  1087. 2.1.1
  1088.     \fIKeypad protocol\fR 
  1089. .sp 9p
  1090. .RT
  1091. .PP
  1092. The Keypad protocol is based on the use of the Keypad facility and Display 
  1093. information elements. The Keypad facility information element may be 
  1094. included in the SETUP and INFORMATION messages. The Display information 
  1095. element may be included in any message sent by the network to the user 
  1096. according to 
  1097. Recommendation Q.931[4].
  1098. .PP
  1099. This protocol applies to supplementary service invocation in the
  1100. user\(hyto\(hynetwork direction, and the keypad facility codes used for the
  1101. invocation of individual supplementary services are network dependent.
  1102. .PP
  1103. The protocol is stimulus in the sense that it does not require any
  1104. knowledge about the invoked supplementary service by the user equipment. 
  1105. It may be used in any state of a call and in association with a call for 
  1106. supplementary service invocation and is applicable to both the basic and 
  1107. primary rate access structures. Paragraph\ 4 contains a detailed specification 
  1108. of this generic 
  1109. protocol.
  1110. .RT
  1111. .sp 1P
  1112. .LP
  1113. 2.1.2
  1114.     \fIFeature key management protocol\fR 
  1115. .sp 9p
  1116. .RT
  1117. .PP
  1118. The Feature key management protocol is based on the use of two
  1119. information elements that are specified in \(sc\ 8: the Feature activation and
  1120. Feature indication information elements. The Feature activation information
  1121. element may be included in the SETUP and in the INFORMATION messages in the
  1122. user\(hyto\(hynetwork direction. The Feature indication information element 
  1123. may be 
  1124. included in various basic call control messages in the network\(hyto\(hyuser
  1125. direction.
  1126. .PP
  1127. This protocol typically applies to supplementary service operation
  1128. during calls but also allows for non\(hycall related supplementary service
  1129. control. Non\(hycall related supplementary service control is accomplished by
  1130. sending an INFORMATION message with the dummy call reference value and which
  1131. contains a Feature activation information element. The user may send a 
  1132. Feature activation request at any time, and the network may send a Feature 
  1133. indication information element at any time. The supplementary service associated 
  1134. with the Feature identifier is service provider dependent and must be coordinated 
  1135. between the user and the service provider at subscription time. As a service
  1136. provider option, more than one service profile may be allocated to an
  1137. interface, but in this case the terminal identification procedures as defined 
  1138. in Annex\ A must be used in order to relate an appropriate service profile 
  1139. to a particular user. 
  1140. .PP
  1141. \fINote\fR \ \(em\ The term \*Qservice profile\*U refers to the information 
  1142. that the network maintains for a given user to characterize the service 
  1143. offered by the network to that user. A portion of this may contain the 
  1144. association of feature identifiers to specific supplementary services. 
  1145. A service profile is normally allocated to an interface but may optionally 
  1146. be allocated to a particular 
  1147. user's terminal equipment or to a group of user's terminal equipment using 
  1148. the procedures as defined in Annex\ A. 
  1149. .PP
  1150. This protocol is stimulus in the sense that it does not require
  1151. knowledge of the invoked supplementary service by the user's terminal
  1152. equipment. Knowledge of the service profile contained in the network and of
  1153. the association of Feature keys to specific supplementary service invocations 
  1154. is required to unambiguously define the requested supplementary service. 
  1155. This protocol is typically applicable to the basic rate access structure. 
  1156. A detailed description of this protocol is contained in \(sc\ 5. 
  1157. .RT
  1158. .sp 1P
  1159. .LP
  1160. 2.1.3
  1161.     \fIFunctional protocol\fR 
  1162. .sp 9p
  1163. .RT
  1164. .PP
  1165. The Functional protocol is based on the use of the Facility
  1166. information element and the FACILITY message, as well as of other specific
  1167. functional messages specified in \(sc\ 7. This protocol is symmetrical,
  1168. and is applicable to both the basic and primary rate access structures.
  1169. .PP
  1170. This protocol is functional in the sense that it requires the
  1171. knowledge of the related supplementary service by the user equipment supporting 
  1172. it. This facilitates user equipment operation without human intervention 
  1173. by 
  1174. defining semantics for the protocol elements which user equipment can process 
  1175. on its own. 
  1176. .PP
  1177. Functional procedures may follow a Keypad or a Feature key
  1178. management supplementary service invocation. Messages that are specific to a
  1179. function are used to invoke supplementary services that require synchronization 
  1180. of resources at both sides of an interface. The common generic 
  1181. message (i.e.,\ the FACILITY message) is used to invoke supplementary services 
  1182. that do not require such resource synchronization. 
  1183. .RT
  1184. .sp 1P
  1185. .LP
  1186. 2.2
  1187.     \fISupport of the various generic protocols\fR 
  1188. .sp 9p
  1189. .RT
  1190. .PP
  1191. Networks may support more than one of these generic protocols for the control 
  1192. of supplementary services. The support of multiple generic 
  1193. protocols is a network option. Users shall be informed by the service provider 
  1194. at subscription time of the supplementary services available, and of the 
  1195. generic protocols supported on their access.
  1196. .bp
  1197. .RT
  1198. .sp 1P
  1199. .LP
  1200. 2.3
  1201.     \fICo\(hyexistence of generic protocols\fR 
  1202. .sp 9p
  1203. .RT
  1204. .PP
  1205. As a general rule, the Functional protocol shall be used unless the network 
  1206. specifies the use of a stimulus protocol for the invocation of certain 
  1207. supplementary services, or the users have subscribed to a Feature key 
  1208. management facility and service profile.
  1209. .PP
  1210. Networks may support one or more of the three generic protocols;
  1211. it is a network option as to whether one or more generic protocols are
  1212. supported on a given access.
  1213. .PP
  1214. In general, the Keypad protocol and Feature key management
  1215. protocol have only local significance while the Functional protocol may have
  1216. other than local significance.
  1217. .PP
  1218. For a given call instance, the protocol applied at a local interface may 
  1219. be different from the one applied at a remote user's interface. For 
  1220. example, one of the two stimulus protocols may be used at the requesting 
  1221. user's interface, while a functional procedure will, in general, be applied 
  1222. at the 
  1223. remote user's interface unless a network chooses, as an option, to use the
  1224. Keypad protocol or Feature key management protocol for supplementary service
  1225. indication or notification in the network\(hyto\(hyuser direction.
  1226. .RT
  1227. .sp 2P
  1228. .LP
  1229. \fB3\fR     \fBArrangements by which co\(hyexistence of protocols may be\fR 
  1230. \fBsupported by a network\fR 
  1231. .sp 1P
  1232. .RT
  1233. .PP
  1234. Some networks may support only one of the generic protocols per
  1235. user access for the invocation of supplementary services. Other networks may
  1236. choose to support a single generic protocol for the control of supplementary
  1237. services, depending on the user access interface type (e.g.,\ Feature key or
  1238. Keypad on the basic access, Functional on the primary access). This has 
  1239. to be arranged at subscription time. 
  1240. .PP
  1241. Networks supporting multiple generic protocols per access in the
  1242. user\(hyto\(hynetwork direction (i.e.,\ for the supplementary service invocation) 
  1243. will implicitly recognize the protocol option chosen by the user on the 
  1244. basis of the received message type or information element type. 
  1245. .PP
  1246. Networks supporting more than one generic protocol per access in the network\(hyto\(hyuser 
  1247. direction (i.e.,\ at the remote user interface) may choose to 
  1248. apply a particular protocol depending on the supplementary service
  1249. characteristics involved. In a case where, for a given supplementary service, 
  1250. more than one protocol can be supported, then the use of the terminal 
  1251. identification procedure as described in Annex\ A may have to be used in 
  1252. order to determine the protocol supported by that user's terminal equipment, 
  1253. as 
  1254. registered at subscription time.
  1255. .PP
  1256. User service profile procedures, as described in Annex A of this
  1257. Recommendation, provide a means of characterizing the service(s) offered to
  1258. different groups of one or more terminals on the same user access interface. 
  1259. A network may, therefore, use a parameter within a user service profile 
  1260. to 
  1261. determine the appropriate procedures for network initiated supplementary
  1262. services towards the associated group of one or more terminals.
  1263. .RT
  1264. .sp 2P
  1265. .LP
  1266. \fB4\fR     \fBKeypad protocol\fR 
  1267. .sp 1P
  1268. .RT
  1269. .PP
  1270. The Keypad protocol is based on the use of the Keypad facility and Display 
  1271. information elements. While the generic procedures associated with 
  1272. Keypad invocation are specified in this section, the allocation of the 
  1273. access codes used to requestB/Findicate a supplementary service are not 
  1274. to be 
  1275. standardized within the CCITT.
  1276. .PP
  1277. An example of the use of the Keypad protocol is given in
  1278. Appendix\ I.
  1279. .RT
  1280. .sp 1P
  1281. .LP
  1282. 4.1
  1283.     \fIGeneral\fR 
  1284. .sp 9p
  1285. .RT
  1286. .PP
  1287. This generic procedure is based on the use of:
  1288. .RT
  1289. .LP
  1290.     \(em
  1291.     the Keypad facility information element by the user to invoke
  1292. a supplementary service from the network by providing access
  1293. codes using either en\(hybloc or overlap sending; and
  1294. .LP
  1295.     \(em
  1296.     the Display information element by the network to give an
  1297. indication to the local or remote user regarding a supplementary
  1298. service being invoked. This procedure may be complemented in the
  1299. case of calls where the Bearer capability information element in
  1300. the SETUP message is coded indicating \*Qspeech\*U or \*Q3.1\ kHz
  1301. audio\*U, by the provision of in\(hyband tones/announcements to the
  1302. user.
  1303. .PP
  1304. \fINote\fR \ \(em\ As a network option, the Keypad facility information
  1305. element
  1306. may be used by the network to give an indication to the user when the network 
  1307. expects an automatic reaction to the received information to acknowledge 
  1308. an 
  1309. invoked supplementary service. As the semantics of the Keypad facility
  1310. information element are not standardized the use of the Keypad facility
  1311. information element in the network\(hyto\(hyuser direction may inhibit terminal
  1312. portability since for a terminal to operate successfully on more than one
  1313. network it must be capable of interpreting various different semantics as
  1314. assigned by the network to the Keypad facility information. In any case, 
  1315. user equipment not supporting this option shall follow the error recovery 
  1316. procedures defined in \(sc\ 5.8 of Recommendation\ Q.931 of receipt of 
  1317. the Keypad facility 
  1318. information element.
  1319. .bp
  1320. .PP
  1321. The Keypad protocol may be used in conjunction with the Feature
  1322. key management (\(sc\ 5) or Functional protocol (\(sc\ 6) during the invocation 
  1323. of a 
  1324. supplementary service.
  1325. .PP
  1326. The Keypad protocol is based on the use of the Keypad facility
  1327. information element within the INFORMATION or SETUP messages during the
  1328. establishment, active and clearing phases of a call.
  1329. .RT
  1330. .sp 1P
  1331. .LP
  1332. 4.2
  1333.     \fIMessages used in the Keypad protocol\fR 
  1334. .sp 9p
  1335. .RT
  1336. .PP
  1337. As specified in Recommendation Q.931, the Keypad facility
  1338. information element may be included in both the SETUP and INFORMATION messages 
  1339. and may be sent in the user\(hyto\(hynetwork direction. 
  1340. .RT
  1341. .sp 1P
  1342. .LP
  1343. 4.3
  1344.     \fICoding of the Keypad facility information element\fR 
  1345. .sp 9p
  1346. .RT
  1347. .PP
  1348. The contents of the Keypad facility information element are a
  1349. string of IA5 characters. The syntax of the IA5 character string and the
  1350. allocation of values for given supplementary services are not subject to 
  1351. CCITT standardization. 
  1352. .RT
  1353. .sp 2P
  1354. .LP
  1355. 4.4
  1356.     \fIElements of procedure\fR 
  1357. .sp 1P
  1358. .RT
  1359. .sp 1P
  1360. .LP
  1361. 4.4.1
  1362.     \fIGeneral\fR 
  1363. .sp 9p
  1364. .RT
  1365. .PP
  1366. The Keypad protocol includes the following aspects:
  1367. .RT
  1368. .LP
  1369.     1)
  1370.     the Keypad protocol may be used during the call
  1371. establishment, active, and clearing phases of a call to invoke
  1372. supplementary services. Supplementary service information is
  1373. conveyed in Keypad facility information elements sent in either
  1374. SETUP or INFORMATION messages;
  1375. .LP
  1376.     2)
  1377.     supplementary service information can be sent from the user
  1378. to the network either en\(hybloc or using overlap sending;
  1379. .LP
  1380.     3)
  1381.     the network may prompt the user to send the required
  1382. information using the Display information element and/or in\(hyband
  1383. tones or announcements. Whether this action shall occur or not
  1384. is supplementary service and network specific. In any case,
  1385. in\(hyband tones or announcements shall only be used when the
  1386. Bearer capability information element indicates \*Qspeech\*U or
  1387. \*Q3.1\ kHz audio\*U;
  1388. .LP
  1389.     4)
  1390.     there may be different combinations of user provided
  1391. information followed by network prompts. Examples of such
  1392. possible combinations are shown in Table\ 4\(hy1/Q.932, where the
  1393. term \*Qstage\*U is used to refer to information sent by the user
  1394. between network prompts (if any).
  1395. .ce
  1396. \fBH.T. [T1.932]\fR 
  1397. .ce
  1398. TABLE\ 4\(hy1/Q.932
  1399. .ce
  1400. \fBExample of stages for sending of information\fR 
  1401. .ps 9
  1402. .vs 11
  1403. .nr VS 11
  1404. .nr PS 9
  1405. .TS
  1406. center box;
  1407. cw(42p) | cw(144p) .
  1408. Number of stages    Sending information 
  1409. _
  1410. .T&
  1411. cw(42p) | lw(144p) .
  1412. 1     {
  1413. All information sent en\(hybloc 
  1414.  }
  1415. .T&
  1416. cw(42p) | lw(144p) .
  1417. 1    All information sent overlap 
  1418. .T&
  1419. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1420. 2    Overlap    Prompt     Overlap
  1421. .T&
  1422. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1423. 2    En\(hybloc    Prompt     En\(hybloc 
  1424. .T&
  1425. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1426. 2    Overlap    Prompt     En\(hybloc
  1427. .T&
  1428. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1429. 2    En\(hybloc    Prompt     Overlap
  1430. .T&
  1431. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1432. 3    Overlap    Prompt     Overlap
  1433. .T&
  1434. cw(42p) | lw(48p) | lw(48p) | lw(48p) .
  1435.     . |  |  | rompt     Overlap, etc.
  1436. .TE
  1437. .LP
  1438. \fINote\fR
  1439. \ \(em\ The number of possible stages is network dependent and may also
  1440. be dependent on the specific supplementry service being invoked.
  1441. .nr PS 9
  1442. .RT
  1443. .ad r
  1444. \fBTable 4\(hy1/Q.932 [T1.932], p.20\fR 
  1445. .sp 1P
  1446. .RT
  1447. .ad b
  1448. .RT
  1449. .LP
  1450. .bp
  1451. .sp 2P
  1452. .LP
  1453. 4.5
  1454.     \fIProcedures at the\fR 
  1455. \fIinvocation interface\fR 
  1456. .sp 1P
  1457. .RT
  1458. .sp 1P
  1459. .LP
  1460. 4.5.1
  1461.     \fIUser procedures\fR 
  1462. .sp 9p
  1463. .RT
  1464. .PP
  1465. The procedures below define how information (using either en\(hybloc or 
  1466. overlap sending) may be sent in a single stage from the user to the network. 
  1467. The procedures are applicable for each stage of user\(hyto\(hynetwork information 
  1468. sending.
  1469. .RT
  1470. .sp 1P
  1471. .LP
  1472. 4.5.1.1
  1473.     \fIEn\(hybloc sending of access codes\fR 
  1474. .sp 9p
  1475. .RT
  1476. .PP
  1477. En\(hybloc sending of supplementary service information is
  1478. accomplished by sending the \*Qcomplete\*U supplementary service information
  1479. in:
  1480. .RT
  1481. .LP
  1482.     \(em
  1483.     the SETUP message, if the supplementary service is being
  1484. invoked during the call establishment; or
  1485. .LP
  1486.     \(em
  1487.     the INFORMATION message, if the supplementary service is
  1488. being invoked from the active phase of the call or during the
  1489. clearing phase of a call.
  1490. .PP
  1491. The term \*Qcomplete\*U supplementary service information means that sufficient 
  1492. supplementary service information is sent to the network to specify a service 
  1493. without any additional network prompting being required. The network determines 
  1494. that the supplementary service information is \*Qcomplete\*U by 
  1495. either:
  1496. .LP
  1497.     \(em
  1498.      analysis of the information contents of the Keypad facility information 
  1499. element; or 
  1500. .LP
  1501.     \(em
  1502.     the presence of a \*Qsending complete\*U indication (see
  1503. Recommendation\ Q.931, \(sc\ 5.1.3).
  1504. .PP
  1505. If the network determines that the information contents of the
  1506. Keypad facility information element are invalid, the network shall use the
  1507. error procedures specified in \(sc\ 4.5.2.3.
  1508. .PP
  1509. If the network determined that the information contents are valid
  1510. and that the user is allowed to invoke the requested service, the network 
  1511. shall respond using the procedures as specified in \(sc\ 4.5.2.1. 
  1512. .RT
  1513. .sp 1P
  1514. .LP
  1515. 4.5.1.2
  1516.     \fIOverlap sending of access codes\fR 
  1517. .sp 9p
  1518. .RT
  1519. .PP
  1520. Overlap sending of supplementary service information is the sending of 
  1521. the \*Qcomplete\*U supplementary service information (see \(sc\ 4.5.1.1 
  1522. for the 
  1523. definition of complete) segmented such that a number of Recommendation\ Q.931
  1524. messages are used to convey the \*Qcomplete\*U supplementary service information. 
  1525. The possible combination of messages: 
  1526. .RT
  1527. .LP
  1528.     a)
  1529.     for supplementary services invoked during call
  1530. establishment, consists of using the SETUP message plus one or
  1531. more INFORMATION messages which will be sent in the overlap
  1532. sending state; or
  1533. .LP
  1534.     b)
  1535.     for supplementary services invoked in
  1536. the active or clearing phases of the call, consists of using two
  1537. or more INFORMATION messages.
  1538. .PP
  1539. For case a), normal overlap sending procedures, as specified in
  1540. Recommendation\ Q.931, \(sc\ 5.1.3, shall be used.
  1541. .PP
  1542. For case b), the transmission or receipt of INFORMATION messages
  1543. shall not cause any change to the Recommendation\ Q.931 call state.
  1544. .PP
  1545. The network shall respond to valid supplementary service
  1546. information with one of the network responses as described in \(sc\ 4.5.2.1. 
  1547. If the supplementary service information is invalid, then the error procedures 
  1548. as 
  1549. described in \(sc\ 4.5.2.3 shall apply.
  1550. .RT
  1551. .sp 2P
  1552. .LP
  1553. 4.5.2
  1554.     \fINetwork procedures\fR 
  1555. .sp 1P
  1556. .RT
  1557. .sp 1P
  1558. .LP
  1559. 4.5.2.1
  1560.     \fINetwork responses to user requests\fR 
  1561. .sp 9p
  1562. .RT
  1563. .PP
  1564. After receiving information from the user, the network may take one of 
  1565. the following actions. Items\ 1)\(hy4) are applicable in the cases of both 
  1566. en\(hybloc
  1567. and overlap sending; item\ 5) is applicable only in the case of information 
  1568. sent using overlap sending. 
  1569. .RT
  1570. .LP
  1571.     1)
  1572.     Clear the call reference via the normal call clearing
  1573. procedures (see Recommendation Q.931, \(sc\ 5.3) including the
  1574. appropriate Cause and optional Display information element(s).
  1575. .LP
  1576.     2)
  1577.     Send a CALL PROCEEDING message to the user.
  1578. .LP
  1579.     \fINote\fR \ \(em\ This network response is only applicable in a case
  1580. where the supplementary service is being invoked during call
  1581. establishment and not in the cases of the supplementary service
  1582. being invoked from the active or clearing phases of the call.
  1583. .bp
  1584. .LP
  1585.     3)
  1586.     Send an INFORMATION or clearing message to the user that
  1587. includes a Display information element containing an appropriate
  1588. response to the request for a supplementary service. The
  1589. receipt of an INFORMATION message by the user shall not cause
  1590. any change to the Recommendation\ Q.931 call state.
  1591. .LP
  1592.     4)
  1593.     Prompt the user for more information using the procedures
  1594. as specified in \(sc\ 4.5.2.2. This further information could be
  1595. additional, or new information input by the user
  1596. or another attempt by the user to re\(hyinput the original
  1597. information correctly. Such procedures are network dependent and
  1598. may be supplementary service specific.
  1599. .LP
  1600.     5)
  1601.     Wait for more overlap information. The allowed waiting
  1602. period is governed by timer T302 in the case of information sent
  1603. in the overlap sending state and call control timers for overlap
  1604. information sent during other phases of the call.
  1605. .PP
  1606. The precise action to be taken is dependent on the specific
  1607. supplementary service being invoked.
  1608. .sp 1P
  1609. .LP
  1610. 4.5.2.2
  1611.     \fINetwork prompting and in\(hyband tone/announcement control\fR 
  1612. .sp 9p
  1613. .RT
  1614. .PP
  1615. The network may prompt the user for more information or may
  1616. provide in\(hyband tones or announcements regardless of whether or not 
  1617. the Keypad facility information element was included in the initial SETUP 
  1618. message. The 
  1619. network shall determine whether prompting and/or in\(hyband tone or announcement 
  1620. control should occur. Possible factors governing the provision of prompting 
  1621. and in\(hyband information are: 
  1622. .RT
  1623. .LP
  1624.     \(em
  1625.     the nature of the supplementary service;
  1626. .LP
  1627.     \(em
  1628.     the value of the inter\(hydigit timer;
  1629. .LP
  1630.     \(em
  1631.     the type of interface; and
  1632. .LP
  1633.     \(em
  1634.     the current status or progress of the supplementary service
  1635. request.
  1636. .PP
  1637. Simultaneously with the application of in\(hyband tones or
  1638. announcements, the network may send a PROGRESS message containing a Progress
  1639. indicator information element with the progress descriptor No.\ 8, \fIIn\(hyband\fR 
  1640. \fIinformation or appropriate pattern now available\fR .
  1641. .PP
  1642. The network may, in addition to an audible prompt (i.e., tone or
  1643. announcement), request information from the user by sending an INFORMATION
  1644. message which contains the Display and/or Signal information elements (but
  1645. shall not contain the Called party number information element).
  1646. .PP
  1647. The sending of the INFORMATION message by the network does not result in 
  1648. a change to the Recommendation\ Q.931 call state. However, when this message 
  1649. is sent in the network overlap sending state, timer\ T302 shall be 
  1650. re\(hyinitialized.
  1651. .PP
  1652. The network may prompt the user more than once (i.e., multiple
  1653. stages may occur), but the network should not prompt the user again prior to
  1654. the user's response, or, when in the overlap sending state, prior to the 
  1655. expiry of timer\ T302. This is to avoid situations where a user's response 
  1656. could be 
  1657. related to two unacknowledged network prompts.
  1658. .PP
  1659. \fINote\fR \ \(em\ As a network option, the Information Request procedures
  1660. described in Annex\ B of this Recommendation may be used to prompt the 
  1661. user for additional information related to a given service request. 
  1662. .RT
  1663. .sp 1P
  1664. .LP
  1665. 4.5.2.3
  1666.     \fIError conditions and treatment\fR 
  1667. .sp 9p
  1668. .RT
  1669. .PP
  1670. An error condition exists in the following circumstances:
  1671. .RT
  1672. .LP
  1673.     a)
  1674.     timer T302 expires and complete information has not been
  1675. received;
  1676. .LP
  1677.     b)
  1678.     information containing a \*Qsending complete\*U indication
  1679. indicating en\(hybloc sending, but the user information sent is not
  1680. complete;
  1681. .LP
  1682.     c)
  1683.     information received by the network (complete or
  1684. incomplete) is invalid. Invalid information is information sent
  1685. with incorrect format or containing invalid facility identifier
  1686. or parameter codes;
  1687. .LP
  1688.     d)
  1689.     the user attempts to invoke a supplementary service to
  1690. which the user has not subscribed or to which the user is not
  1691. allowed access.
  1692. .PP
  1693. The action to be taken by the network in these situations is as
  1694. follows.
  1695. .PP
  1696. \fINote\fR \ \(em\ The text below identifies possible actions that may 
  1697. be taken in an error situation. The specific action to be taken is network 
  1698. and 
  1699. supplementary service dependent.
  1700. .bp
  1701. .RT
  1702. .sp 1P
  1703. .LP
  1704. 4.5.2.3.1
  1705.     \fISupplementary service being invoked during call\fR 
  1706. \fIestablishment\fR 
  1707. .sp 9p
  1708. .RT
  1709. .PP
  1710. The network shall take one of the following actions:
  1711. .RT
  1712. .LP
  1713.     i)
  1714.     In\(hyband tones or announcements are applied. If a SETUP
  1715. ACKNOWLEDGE message has not already been sent, the network shall
  1716. send a CALL PROCEEDING message to the user, indicating the
  1717. B\(hychannel to be used and including the Progress indicator
  1718. information element with progress descriptor No.\ 8, \fIIn\(hyband\fR 
  1719. \fIinformation or appropriate pattern is now available\fR .
  1720. .LP
  1721.     If a SETUP ACKNOWLEDGE message has already been sent, the
  1722. network shall send a PROGRESS message to the user, including the
  1723. Progress indicator information element with the progress
  1724. descriptor No.\ 8, \fIIn\(hyband information or appropriate pattern\fR 
  1725. \fIis now available\fR .
  1726. .LP
  1727.     The network may prompt the user using the procedures as
  1728. specified in \(sc\ 4.5.2.2 to re\(hyinput the required information.
  1729. Otherwise, after the in\(hyband tone or announcement has been
  1730. applied, the call reference shall be cleared by either the user
  1731. initiating call clearing or the network initiating call
  1732. clearing at the expiry of a tone or announcement timer. Both the
  1733. network and the user shall use the clearing procedures as
  1734. specified in Recommendation\ Q.931, \(sc\ 5.3.
  1735. .LP
  1736.     ii)
  1737.     No in\(hyband tones or announcements are to be applied. The
  1738. call reference shall be cleared by the network initiating call
  1739. clearing procedures as specified in Recommendation\ Q.931,
  1740. \(sc\ 5.3.
  1741. .sp 1P
  1742. .LP
  1743. 4.5.2.3.2
  1744.     \fISupplementary service being invoked from the active\fR 
  1745. \fIstate or during the call clearing phase\fR 
  1746. .sp 9p
  1747. .RT
  1748. .PP
  1749. The network shall take one of the following actions:
  1750. .RT
  1751. .LP
  1752.     i)
  1753.     In\(hyband tones or announcements are applied. The network
  1754. may prompt the user using the procedures as specified in
  1755. \(sc\ 4.5.2.2 to re\(hyinput the request. Otherwise, depending on the
  1756. specific supplementary service being invoked, the call shall
  1757. either be cleared or remain in the same call state. In the case
  1758. where the call is cleared, clearing shall occur after the
  1759. in\(hyband tone or announcement has been applied. Clearing shall
  1760. occur either by the user initiating call clearing or by the
  1761. network initiating call clearing at the expiry of a tone or
  1762. announcement timer. Both the network and the user shall
  1763. use the clearing procedures as specified in
  1764. Recommendation\ Q.931, \(sc\ 5.3.
  1765. .LP
  1766.     ii)
  1767.     No in\(hyband tones or announcements are to be applied.
  1768. Depending on the specific supplementary service being
  1769. invoked, the call shall either be cleared or remain in the same
  1770. call state. In the case where the call is to be cleared, the
  1771. call reference shall be cleared by the network initiating call
  1772. clearing using the procedures as specified in
  1773. Recommendation\ Q.931, \(sc\ 5.3. If the call remains in the same
  1774. call state, the user may be informed that the supplementary
  1775. service request was unsuccessful by the network sending an
  1776. INFORMATION message in accordance with \(sc\ 4.5.2.1,
  1777. item\ 3).
  1778. .sp 1P
  1779. .LP
  1780. 4.6
  1781.     \fIProcedures at the remote interface\fR 
  1782. .sp 9p
  1783. .RT
  1784. .PP
  1785. The Display and/or Signal information elements can be used for the purpose 
  1786. of providing notification to the remote user from the network. In this 
  1787. case, however, this information is used simply for the purpose of informing 
  1788. the human user, and no automatic reaction to the received information is 
  1789. to be 
  1790. performed by the user's equipment itself.
  1791. .RT
  1792. .sp 2P
  1793. .LP
  1794. \fB5\fR     \fBFeature key management protocol\fR 
  1795. .sp 1P
  1796. .RT
  1797. .PP
  1798. The Feature key management protocol is a mechanism allowing users to invoke 
  1799. network supplementary services. As these are stimulus procedures, the protocol 
  1800. elements do not, in and of themselves, identify the service invoked. To 
  1801. determine the service invoked requires knowledge of the user's service 
  1802. profile maintained in the network. No call state changes directly occur by
  1803. these procedures.
  1804. .PP
  1805. The Feature key management protocol is based on two information
  1806. elements: Feature activation and Feature indication.  The Feature activation
  1807. information element is the means by which a user requests a supplementary
  1808. service. The Feature activation information element contains a feature
  1809. identifier number which the network then maps to the corresponding service 
  1810. as indicated by that user's service profile. The user's equipment need 
  1811. not have 
  1812. any knowledge of what service is being indicated by the feature identifier
  1813. number and the user may send a feature request at any time.
  1814. .bp
  1815. .PP
  1816. Feature indication is the means by which a response to a feature
  1817. activation is indicated by the network. The feature identifier number
  1818. correlates the network's response with a user's request and/or an indicator
  1819. associated with a user's equipment. The Feature indication information 
  1820. element also contains a status indicator. The status indicator indicates 
  1821. the status of the requested service and may be used by the user's equipment 
  1822. as appropriate 
  1823. with its man\(hymachine interface.
  1824. .RT
  1825. .sp 1P
  1826. .LP
  1827. 5.1
  1828.     \fIMessages\fR 
  1829. .sp 9p
  1830. .RT
  1831. .PP
  1832. The Feature activation and Feature indication information elements may 
  1833. be present in several of the messages defined in Recommendation\ Q.931. 
  1834. The Feature activation information element may appear in the following 
  1835. messages in the user\(hyto\(hynetwork direction: 
  1836. .RT
  1837. .LP
  1838.     a)
  1839.     SETUP
  1840. .LP
  1841.     b)
  1842.     INFORMATION.
  1843. .PP
  1844. The Feature indication information element may be sent in the
  1845. network\(hyto\(hyuser direction in the following messages:
  1846. .LP
  1847.     a)
  1848.     SETUP
  1849. .LP
  1850.     b)
  1851.     SETUP ACKNOWLEDGE
  1852. .LP
  1853.     c)
  1854.     CONNECT
  1855. .LP
  1856.     d)
  1857.     CALL PROCEEDING
  1858. .LP
  1859.     e)
  1860.     ALERTING
  1861. .LP
  1862.     f
  1863. )
  1864.     INFORMATION
  1865. .LP
  1866.     g)
  1867.     DISCONNECT
  1868. .LP
  1869.     h)
  1870.     RELEASE
  1871. .LP
  1872.     i)
  1873.     RELEASE COMPLETE.
  1874. .sp 2P
  1875. .LP
  1876. 5.2
  1877.     \fIProcedures\fR 
  1878. .sp 1P
  1879. .RT
  1880. .sp 1P
  1881. .LP
  1882. 5.2.1
  1883.     \fIAssumptions and restrictions\fR 
  1884. .sp 9p
  1885. .RT
  1886. .LP
  1887.     a)
  1888.     These procedures assume that only one Feature activation
  1889. request will appear in a message.
  1890. .LP
  1891.     b)
  1892.     The phrase \*Qcall associated services\*U used herein is defined
  1893. as services which act upon or relate to an existing call (as
  1894. defined by the existence of a call reference).
  1895. .LP
  1896.     c)
  1897.     These procedures are used for the invocation of
  1898. supplementary services which relate to predefined specific
  1899. bearer capabilities andB/For are context dependent. Hence the
  1900. capability to include protocol elements to indicate the bearer
  1901. capability that the supplementary service is to act upon is not
  1902. provided.
  1903. .sp 1P
  1904. .LP
  1905. 5.2.2
  1906.     \fIInvocation of supplementary services\fR 
  1907. .sp 9p
  1908. .RT
  1909. .PP
  1910. The user may request a feature by including a Feature activation
  1911. information element in the messages defined in \(sc\ 5.1. If the INFORMATION
  1912. message is used, it may be sent at any time. The user will indicate the 
  1913. desired feature by specifying the appropriate value in a feature identifier 
  1914. number.
  1915. .RT
  1916. .sp 1P
  1917. .LP
  1918. 5.2.2.1
  1919.     \fIDetermination of call reference in the INFORMATION message\fR 
  1920. .sp 9p
  1921. .RT
  1922. .PP
  1923. When the Feature activation information element is sent in the
  1924. INFORMATION message, then the following rules apply:
  1925. .RT
  1926. .LP
  1927.     a)
  1928.     if no call references exist, then the dummy call reference
  1929. must be used (for this non\(hycall associated service type);
  1930. .LP
  1931.     b)
  1932.     if a call reference(s) has been established, then that
  1933. value may be used regardless of whether the service type
  1934. is call associated or non\(hycall associated;
  1935. .LP
  1936.     c)
  1937.     if a call reference(s) has been established, the dummy call
  1938. reference may be used only if the service type is non\(hycall
  1939. associated. If the service type is call associated, then the
  1940. appropriate call reference must be used. An exception to this
  1941. rule is when only one call is established. In this instance it
  1942. is permissible for the user to use the dummy call reference for
  1943. either service type.
  1944. .bp
  1945. .PP
  1946. This is summarized in Figure 5\(hy1/Q.932.
  1947. .LP
  1948. .rs
  1949. .sp 13P
  1950. .ad r
  1951. \fBFigure 5\(hy1/Q.931 [T2.932] \ \ 
  1952. (\*`a traiter comme tableau), p.21\fR 
  1953. .sp 1P
  1954. .RT
  1955. .ad b
  1956. .RT
  1957. .PP
  1958. It is always correct for the user's equipment to use the dummy
  1959. call reference when no calls exist, or to use an established call reference 
  1960. if one exists, independent of the service type. 
  1961. .sp 1P
  1962. .LP
  1963. 5.2.3
  1964.     \fINetwork responses\fR 
  1965. .sp 9p
  1966. .RT
  1967. .PP
  1968. The network may respond to a Feature activation request in several ways. 
  1969. This action will be supplementary service and network specific. 
  1970. .RT
  1971. .sp 2P
  1972. .LP
  1973. 5.2.3.1
  1974.     \fINormal responses\fR 
  1975. .sp 1P
  1976. .RT
  1977. .sp 1P
  1978. .LP
  1979. 5.2.3.1.1
  1980.     \fIReturn of a Feature indication\fR 
  1981. .sp 9p
  1982. .RT
  1983. .PP
  1984. The network may return a Feature indication information element in an INFORMATION 
  1985. message or any other appropriate call control message as defined in \(sc\ 
  1986. 5.1. The feature indication may or may not have the same feature 
  1987. identifier number as was present in the original feature activation request.
  1988. The status indicator will be provided as appropriate to the specific
  1989. supplementary service requested.
  1990. .RT
  1991. .sp 1P
  1992. .LP
  1993. 5.2.3.1.2
  1994.     \fIPrompting for further information\fR 
  1995. .sp 9p
  1996. .RT
  1997. .PP
  1998. The network may prompt the user for more information. When in the overlap 
  1999. sending state, it may do so using the information request procedures 
  2000. (described in Annex\ B).
  2001. .PP
  2002. The user's response shall follow normal overlap sending procedures
  2003. as defined in Recommendation\ Q.931. As a network option, the information
  2004. request procedures described in Annex\ B of this Recommendation may be 
  2005. used to prompt the user for additional information related to a given service 
  2006. request.
  2007. .RT
  2008. .sp 1P
  2009. .LP
  2010. 5.2.3.1.3
  2011.     \fIImplicit response\fR 
  2012. .sp 9p
  2013. .RT
  2014. .PP
  2015. The network, under certain situations, may not return any explicit indication 
  2016. to the user after a feature activation request. In this case the 
  2017. response is implicit, such as the acknowledgement inherent in providing the
  2018. service.
  2019. .RT
  2020. .sp 1P
  2021. .LP
  2022. 5.2.3.1.4
  2023.     \fIReturn of Signal, Cause, or Display information elements\fR 
  2024. .sp 9p
  2025. .RT
  2026. .PP
  2027. The network may return any combination of Signal, Cause, or Display information 
  2028. elements in conjunction with the responses as described in 
  2029. \(sc\ 5.2.3.1. The use of these information elements is supplementary service 
  2030. and network specific. Coding and the appropriate messages that may contain 
  2031. these 
  2032. information elements are as defined in Recommendation\ Q.931.
  2033. .bp
  2034. .RT
  2035. .sp 1P
  2036. .LP
  2037. 5.2.3.2
  2038.     \fIResponses during error conditions\fR 
  2039. .sp 9p
  2040. .RT
  2041. .PP
  2042. When an error condition exists (as defined in \(sc\ 5.2.5), the
  2043. network may:
  2044. .RT
  2045. .LP
  2046.     a)
  2047.     Respond with one or more of the following options:
  2048. .LP
  2049.     1)
  2050.     return a Feature indication information element;
  2051. .LP
  2052.     2)
  2053.     prompt for further information (see Annex B);
  2054. .LP
  2055.     3)
  2056.     provide an implicit response; or
  2057. .LP
  2058.     4)
  2059.     return Signal, Cause, or Display information
  2060. elements.
  2061. .LP
  2062.     b)
  2063.     Ignore the Feature activation request and not respond at
  2064. all.
  2065. .LP
  2066.     c)
  2067.     Clear appropriate existing calls in conjunction with the
  2068. above actions.
  2069. .sp 2P
  2070. .LP
  2071. 5.2.4
  2072.     \fIGeneral aspects\fR 
  2073. .sp 1P
  2074. .RT
  2075. .sp 1P
  2076. .LP
  2077. 5.2.4.1
  2078.     \fIUse of Feature indication information elements independent\fR 
  2079. \fIof a feature request\fR 
  2080. .sp 9p
  2081. .RT
  2082. .PP
  2083. The network may choose to send Feature indication information at
  2084. any time independent of the status of any call(s). Multiple Feature indication 
  2085. information elements may be returned in an INFORMATION message or in an 
  2086. appropriate call control message if more than one indicator is to be
  2087. updated.
  2088. .RT
  2089. .sp 1P
  2090. .LP
  2091. 5.2.4.2
  2092.     \fIDeactivation procedures\fR 
  2093. .sp 9p
  2094. .RT
  2095. .PP
  2096. When explicitly deactivating a supplementary service, two methods may be 
  2097. used: 
  2098. .RT
  2099. .LP
  2100.     a)
  2101.     sending of a feature activation request with the same
  2102. feature identifier may deactivate the supplementary service.
  2103. Some supplementary services may be \*Qtoggled\*U on and off;
  2104. .LP
  2105.     b)
  2106.     sending of a feature activation request with a different
  2107. feature identifier which is explicitly defined (between the user
  2108. and network) as the deactivator for that particular
  2109. supplementary service.
  2110. .sp 1P
  2111. .LP
  2112. 5.2.4.3
  2113.     \fIClearing of a call\fR 
  2114. .sp 9p
  2115. .RT
  2116. .PP
  2117. If a Feature activation information element is sent using the call reference 
  2118. of an active call, and that call is cleared for some reason, then 
  2119. there does not exist a call reference with which to correlate the feature
  2120. indication. If a Feature indication information element is to be returned, 
  2121. then one of the following options may be used: 
  2122. .RT
  2123. .LP
  2124.     a)
  2125.     the network may send a Feature indication information
  2126. element in one of the call clearing messages (i.e., DISCONNECT,
  2127. RELEASE, or RELEASE COMPLETE);
  2128. .LP
  2129.     b)
  2130.     the network may send a Feature indication information
  2131. element in an INFORMATION message after clearing has occurred
  2132. using the dummy call reference.
  2133. .sp 2P
  2134. .LP
  2135. 5.2.5
  2136.     \fIError conditions\fR 
  2137. .sp 1P
  2138. .RT
  2139. .sp 1P
  2140. .LP
  2141. 5.2.5.1
  2142.     \fIInvalid feature activation request\fR 
  2143. .sp 9p
  2144. .RT
  2145. .PP
  2146. If a user requests a feature using an invalid feature identifier
  2147. number, the network may take actions specified in \(sc\ 5.2.3.2 as appropriate. 
  2148. An invalid feature identifier number is one in which the user has not subscribed 
  2149. to a corresponding service, or the value is not understood by the service 
  2150. provider (e.g.,\ out of range).
  2151. .RT
  2152. .sp 1P
  2153. .LP
  2154. 5.2.5.2
  2155.     \fIInvalid call reference\fR 
  2156. .sp 9p
  2157. .RT
  2158. .PP
  2159. If a user violates the use of the call reference as stated in
  2160. \(sc\ 5.2.2.1, the network should not provide the service and should respond as
  2161. indicated in \(sc\ 5.2.3.2.
  2162. .RT
  2163. .sp 1P
  2164. .LP
  2165. 5.2.5.3
  2166.     \fISending of multiple feature activation requests\fR 
  2167. .sp 9p
  2168. .RT
  2169. .PP
  2170. If a sequence of feature activation requests is received in
  2171. separate messages so rapidly that the network cannot respond to the first
  2172. feature activation request prior to receiving a subsequent feature activation 
  2173. request, the network may take one of the following actions: 
  2174. .RT
  2175. .LP
  2176.     a)
  2177.     act upon all feature activation requests by returning
  2178. multiple Feature indication information elements (or other
  2179. responses as detailed in \(sc\ 5.2.3.1). These may be sent in a
  2180. single message or in multiple messages;
  2181. .bp
  2182. .LP
  2183.     b)
  2184.     act upon the first feature activation request by returning
  2185. a single response. This response should correspond to the first
  2186. feature activation request. Feature activation requests after
  2187. the first request are discarded and ignored by the
  2188. network.
  2189. .PP
  2190. The determination of which action to take is network and
  2191. supplementary service specific.
  2192. .LP
  2193. \fB6\fR     \fBFunctional protocol\fR 
  2194. .sp 1P
  2195. .RT
  2196. .sp 2P
  2197. .LP
  2198. 6.1
  2199.     \fIGeneral\fR 
  2200. .sp 1P
  2201. .RT
  2202. .sp 1P
  2203. .LP
  2204. 6.1.1
  2205.     \fIIntroduction\fR 
  2206. .sp 9p
  2207. .RT
  2208. .PP
  2209. This section specifies the functional signalling procedures for the control 
  2210. of supplementary services at the user\(hynetwork interface. This generic 
  2211. protocol utilizes functions and services provided by Recommendations\ Q.930 | 5] 
  2212. and Q.931 | 4] basic call control procedures and the functions of the data 
  2213. link layer as defined in Recommendations\ Q.920 | 6]/Q.921 | 3]. 
  2214. .RT
  2215. .sp 1P
  2216. .LP
  2217. 6.1.2
  2218.     \fIScope of the procedures\fR 
  2219. .sp 9p
  2220. .RT
  2221. .PP
  2222. The procedures defined in \(sc\ 6 specify the basic methodology for
  2223. the control (e.g., invocation, notification, cancellation,\ etc.) of
  2224. supplementary services. The procedures are independent of whether or not the
  2225. user\(hynetwork interface is a basic or primary rate interface.
  2226. .RT
  2227. .sp 1P
  2228. .LP
  2229. 6.1.3
  2230.     \fICategories of procedures\fR 
  2231. .sp 9p
  2232. .RT
  2233. .PP
  2234. Two categories of procedures are defined for the functional
  2235. signalling for supplementary services. The first category, called the separate 
  2236. message approach, utilizes separate message types to indicate a desired 
  2237. function. The HOLD and RETRIEVE set of messages are identified for this
  2238. category.
  2239. .PP
  2240. The second category, called the common information element
  2241. procedure, utilizes the Facility information element and applies only to
  2242. supplementary services that do not require synchronization of resources 
  2243. between the user and the network. 
  2244. .PP
  2245. Both categories are specified in a symmetrical manner and can be
  2246. signalled both in the network\(hyto\(hyuser and the user\(hyto\(hynetwork 
  2247. directions. 
  2248. .RT
  2249. .sp 1P
  2250. .LP
  2251. 6.1.4
  2252.     \fISupplementary service functions\fR 
  2253. .sp 9p
  2254. .RT
  2255. .PP
  2256. The control of supplementary services by either the network or the user 
  2257. includes the following cases: 
  2258. .RT
  2259. .LP
  2260.     a)
  2261.     the invocation of supplementary services during the
  2262. establishment of a call;
  2263. .LP
  2264.     b)
  2265.     the invocation of supplementary services during the
  2266. clearing of a call;
  2267. .LP
  2268.     c)
  2269.     the invocation of call related supplementary services
  2270. during the active state of a call;
  2271. .LP
  2272.     d)
  2273.     the invocation or registration of supplementary services
  2274. independent from an active call;
  2275. .LP
  2276.     e)
  2277.     the invocation of multiple, different supplementary services
  2278. within a single message;
  2279. .LP
  2280.     f
  2281. )
  2282.     the invocation of supplementary services related to
  2283. different calls;
  2284. .LP
  2285.     g)
  2286.     cancellation of invoked supplementary services and
  2287. notification to the initiator of the supplementary service.
  2288. .PP
  2289. The correlation of a call related supplementary service and the
  2290. call which it modifies is provided by use of the call reference [cases\ 
  2291. a), b), c), e), f 
  2292. ) and\ g) listed above].
  2293. .PP
  2294. The correlation of call independent supplementary service invocations and 
  2295. their responses, is provided by the combination of the call reference of 
  2296. the message containing the Facility information element and the invoke
  2297. identifier present within the Facility information element itself [refer to
  2298. cases\ d), e) and\ g)].
  2299. .PP
  2300. The identification of different supplementary service invocations
  2301. within one single message is provided by the invoke identifier of the
  2302. corresponding Facility information element [refer to cases\ e) and\ g)]. The
  2303. identification of supplementary service invocations related to different 
  2304. calls is provided by different messages with the corresponding call reference 
  2305. of the appropriate call [refer to case\ f)], i.e.,\ different call reference 
  2306. values are used to identify each call individually. 
  2307. .bp
  2308. .RT
  2309. .sp 1P
  2310. .LP
  2311. 6.2
  2312.     \fISeparate messages category\fR 
  2313. .sp 9p
  2314. .RT
  2315. .PP
  2316. The messages defined in this section are specified as separate
  2317. functional messages for invoking specific functions which require changes of
  2318. the resources and auxiliary state and also require synchronization of the
  2319. peer\(hyto\(hypeer state machines. Therefore, these functions cannot be 
  2320. performed in conjunction with the call establishment and clearing procedures 
  2321. but may be used in conjunction with various supplementary services. The 
  2322. functions of these 
  2323. messages are not to be duplicated or overlapped by those of the Facility
  2324. information element.
  2325. .PP
  2326. The following individual messages are defined:
  2327. .RT
  2328. .LP
  2329.     HOLD
  2330. .LP
  2331.     HOLD ACKNOWLEDGE
  2332. .LP
  2333.     HOLD REJECT
  2334. .LP
  2335.     RETRIEVE
  2336. .LP
  2337.     RETRIEVE ACKNOWLEDGE
  2338. .LP
  2339.     RETRIEVE REJECT.
  2340. .sp 1P
  2341. .LP
  2342. 6.2.1
  2343.     \fIHold and Retrieve functions\fR 
  2344. .sp 9p
  2345. .RT
  2346. .PP
  2347. The Hold function is used to put an existing call which is in the establishment 
  2348. or in the active phase in the Call Held auxiliary state. By 
  2349. default, it reserves the B\(hychannel in use (if any) or any other B\(hychannel 
  2350. (if none was already reserved) for that user which is identified by a Connection 
  2351. Endpoint Suffix (CES), as defined in Recommendation\ Q.921.  In addition, the
  2352. call reference of the held call shall be retained for possible subsequent 
  2353. call retrieval and channel reconnection. 
  2354. .PP
  2355. As an option, based on a subscription arrangement between the user
  2356. and the service provider, the B\(hychannel may be released for subsequent 
  2357. re\(hyuse by the network for another call. 
  2358. .PP
  2359. On receipt of a HOLD message the user or the network shall return
  2360. a HOLD ACKNOWLEDGE message, provided that the requested function can be
  2361. performed.  The network disconnects any B\(hychannel allocated to the call in
  2362. progress or active when putting that call in the Call Held auxiliary state.
  2363. .PP
  2364. \fINote\ 1\fR \ \(em\ Generally, only one B\(hychannel is reserved for 
  2365. each user 
  2366. having put one (or more) call(s) on hold. However, as a subscription
  2367. option, a network may reserve more than one B\(hychannel to a user.
  2368. .PP
  2369. \fINote\ 2\fR \ \(em\ Enhancements to the procedures may be required for users
  2370. requesting the non\(hyreservation of the B\(hychannel, on a per call basis.
  2371. .PP
  2372. The HOLD ACKNOWLEDGE message puts the call in the held auxiliary
  2373. state and indicates that the Hold function has been performed. The HOLD 
  2374. REJECT message indicates that the hold request was denied and returns the 
  2375. call to the condition it was in prior to the hold request. The HOLD REJECT 
  2376. message contains the Cause information element with e.g., cause No.\ 29, 
  2377. \fIFacility rejected\fR , or No.\ 50, \fIRequested facility not subscribed\fR 
  2378. , or No.\ 69, \fIRequested facility\fR \fInot implemented\fR . 
  2379. .PP
  2380. The Retrieve function reconnects the user to the requested B\(hychannel. 
  2381. The RETRIEVE message requests that a call be retrieved. The RETRIEVE 
  2382. ACKNOWLEDGE message indicates that the Retrieve function has been performed.
  2383. The RETRIEVE REJECT message indicates that the retrieve request was denied. 
  2384. The RETRIEVE REJECT message contains the Cause information element with 
  2385. e.g., cause No.\ 44, \fIRequested channel not available\fR , or No.\ 34, 
  2386. \fIno channel available\fR . 
  2387. .PP
  2388. The HOLD and RETRIEVE families of message may be used in a
  2389. symmetrical manner.
  2390. .RT
  2391. .sp 1P
  2392. .LP
  2393. 6.2.2
  2394.     \fIHold procedures\fR 
  2395. .sp 9p
  2396. .RT
  2397. .PP
  2398. The Hold function should be invoked in association with an existing call 
  2399. (i.e.,\ during the establishment or active phase of a call). 
  2400. .PP
  2401. The invocation of the Hold function does not affect the existing
  2402. Recommendation\ Q.931 call states but does affect the auxiliary state. The
  2403. request for placing a call on hold places the auxiliary state in the Hold
  2404. Request state. The responding entity will acknowledge this request with 
  2405. a HOLD ACKNOWLEDGE message if this operation was successful. This will 
  2406. result in the auxiliary state being put in the Call Held state. If the 
  2407. requested Hold 
  2408. function cannot be obtained, then a HOLD REJECT message will be returned 
  2409. with the appropriate cause. This will result in the auxiliary state returning 
  2410. to the Idle state. 
  2411. .bp
  2412. .RT
  2413. .sp 1P
  2414. .LP
  2415. 6.2.3
  2416.     \fIRetrieve procedures\fR 
  2417. .sp 9p
  2418. .RT
  2419. .PP
  2420. The Retrieve function is requested by sending a RETRIEVE message. This 
  2421. message may be sent while the auxiliary state is in the Call Held state. 
  2422. .PP
  2423. The RETRIEVE message may indicate a preferred, any, or exclusive
  2424. channel. Procedures for the use of the Channel identification information
  2425. element are as defined for basic call control. Upon the sending of the
  2426. RETRIEVE message, the auxiliary state of the initiator's terminal would 
  2427. be the Retrieve Request state. 
  2428. .PP
  2429. If the Retrieve request is successful, the RETRIEVE ACKNOWLEDGE
  2430. message will be returned with the selected B\(hychannel indicated. The 
  2431. initiator should not assume that call retrieval has occurred until it receives 
  2432. this 
  2433. message. The auxiliary state would then return to the Idle state.
  2434. .PP
  2435. If the Retrieve request is not successful, the RETRIEVE REJECT
  2436. message will be returned with an appropriate cause. The auxiliary state 
  2437. machine would then remain in the Call Held state. 
  2438. .RT
  2439. .sp 1P
  2440. .LP
  2441. 6.2.4
  2442.     \fIAuxiliary states for hold and retrieve\fR 
  2443. .sp 9p
  2444. .RT
  2445. .PP
  2446. It is possible to place a call on hold in the Outgoing Call
  2447. Proceeding, Call Delivered, or the Active state. The concept of dimensioned
  2448. state space is being introduced to ensure state synchronization between the
  2449. user and the network. This concept suggests dimensioning the call state 
  2450. machine into two dimensions. In other words, there would be two states 
  2451. associated with each call. The first would be a Recommendation\ Q.931 call 
  2452. state and the second would be an auxiliary state associated with Hold. 
  2453. Suppose the dimensioned state space is represented by two coordinates: 
  2454. one is a Recommendation\ Q.931 call 
  2455. state coordinate and the other is a Hold coordinate. If a Recommendation\ 
  2456. Q.931 call state transition occurs, the former coordinate is updated. If 
  2457. a call is 
  2458. put on hold, the hold coordinate is updated. When the held call is reconnected, 
  2459. the hold coordinate is again updated. 
  2460. .PP
  2461. There are four auxiliary states associated with the Hold and Retrieve functions: 
  2462. .RT
  2463. .LP
  2464.     i)
  2465.     Idle;
  2466. .LP
  2467.     ii)
  2468.     Hold Request \(em A request has been made for the Hold
  2469. function;
  2470. .LP
  2471.     iii)
  2472.     Call Held \(em The call is held;
  2473. .LP
  2474.     iv)
  2475.     Retrieve Request \(em A request has been made for the Retrieve
  2476. function.
  2477. .sp 1P
  2478. .LP
  2479. 6.2.5
  2480.     \fIAn example of dimensioned state space\fR 
  2481. .sp 9p
  2482. .RT
  2483. .PP
  2484. Suppose a call is in the Outgoing Call Proceeding state. The
  2485. dimensioned state space would be:
  2486. .RT
  2487. .sp 1P
  2488. .ce 1000
  2489. (Outgoing Call Proceeding, Idle)
  2490. .ce 0
  2491. .sp 1P
  2492. .PP
  2493. Now the user requests the Hold function.  The dimensioned state
  2494. space would become:
  2495. .sp 1P
  2496. .ce 1000
  2497. (Outgoing Call Proceeding, Hold Request)
  2498. .ce 0
  2499. .sp 1P
  2500. .PP
  2501. The call is then put on Hold. The user becomes aware of this
  2502. upon receiving the HOLD ACKNOW
  2503. LEDGE message from the network. The
  2504. dimensioned state space would now be:
  2505. .sp 1P
  2506. .ce 1000
  2507. (Outgoing Call Proceeding, Call Held)
  2508. .ce 0
  2509. .sp 1P
  2510. .PP
  2511. The user may receive subsequent call progress messages changing
  2512. the dimensioned state space to:
  2513. .sp 1P
  2514. .ce 1000
  2515. (Active, Call Held)
  2516. .ce 0
  2517. .sp 1P
  2518. .PP
  2519. Now the user requests the Retrieve function. The dimensioned state space 
  2520. would become: 
  2521. .sp 1P
  2522. .ce 1000
  2523. (Active, Retrieve Request)
  2524. .ce 0
  2525. .sp 1P
  2526. .PP
  2527. When a call is reconnected, the dimensioned state space would
  2528. be:
  2529. .sp 1P
  2530. .ce 1000
  2531. (Active, Idle)
  2532. .ce 0
  2533. .sp 1P
  2534. .LP
  2535. 6.3
  2536.     \fICommon information element category\fR 
  2537. .sp 9p
  2538. .RT
  2539. .PP
  2540. The Common information element category applies only to
  2541. supplementary services where no synchronization of resources is required
  2542. between the two signalling entities. However, the user equipment is required 
  2543. to have the capability to track the operation of the supplementary service 
  2544. procedures through various Recommendation\ Q.931 call states.  The procedures
  2545. are symmetrical and applicable to both user\(hynetwork and NT2\(hyNT2 applications. 
  2546. .bp
  2547. .PP
  2548. A REGISTER, a FACILITY or an existing Recommendation Q.931 call
  2549. control message is used to carry the Facility information element which
  2550. requests the desired supplementary service.
  2551. .PP
  2552. This functional procedure provides a flexible and open ended
  2553. approach to the provision of supplementary service protocols and:
  2554. .RT
  2555. .LP
  2556.     \(em
  2557.     allows new services to be easily introduced;
  2558. .LP
  2559.     \(em
  2560.     allows multiple supplementary service invocations within one
  2561. message;
  2562. .LP
  2563.     \(em
  2564.     supports supplementary services with a large number of
  2565. variants without a proliferation of new messages;
  2566. .LP
  2567.     \(em
  2568.     supports non\(hycall associated supplementary services.
  2569. .PP
  2570. In addition, the use of the FACILITY message allows the actions
  2571. and events related to supplementary services to be clearly separated from 
  2572. those associated with basic call control, hence providing improved stability 
  2573. to the basic call control procedures of Recommendation\ Q.931. 
  2574. .sp 1P
  2575. .LP
  2576. 6.3.1
  2577.     \fICall related supplementary service procedures\fR 
  2578. .sp 9p
  2579. .RT
  2580. .PP
  2581. For call related supplementary service procedures initiated at call establishment 
  2582. or call clearing, the procedures for call control as specified in \(sc\(sc\ 
  2583. 5 and\ 6 of Recommendation\ Q.931 are utilized. This enables, for example, 
  2584. the originating user to send a supplementary service invocation within 
  2585. a SETUP message and to receive from the remote user a return result, return 
  2586. error, or reject component type in the Facility information element within 
  2587. an ALERTING 
  2588. message, CONNECT message, or any other appropriate message from the service
  2589. provider. If for some reason the network or user is not able to process the
  2590. call related invocation of a supplementary service contained in an outgoing
  2591. SETUP message, then the following options apply:
  2592. .RT
  2593. .LP
  2594.     1)
  2595.     the network or user may clear the call request and reject
  2596. the supplementary service invocation by means of
  2597. a RELEASE COMPLETE message which contains the Cause information
  2598. element and a return error or reject component type with the
  2599. appropriate parameters in the Facility information element;
  2600. .LP
  2601.     2)
  2602.     the network or user may continue to process the call
  2603. request according to normal Recommendation\ Q.931 call control
  2604. procedures, and reject the supplementary service invocation by
  2605. including a return error or reject component type with an
  2606. appropriate data element in the Facility information element by
  2607. means of a FACILITY message or in any appropriate
  2608. Recommendation\ Q.931 message;
  2609. .LP
  2610.     3)
  2611.     the network or user may continue to process the call request
  2612. according to the Recommendation\ Q.931 call control procedures,
  2613. and ignore the supplementary service invocation.
  2614. .PP
  2615. The option to be used depends on the individual supplementary
  2616. service procedures, which are the subject of other Recommendations.
  2617. .PP
  2618. For call related supplementary service invocations during the
  2619. Active state of a call, the FACILITY message is used for the exchange of the
  2620. Facility information elements over the existing signalling connection. This
  2621. signalling connection is identified by the call reference of the corresponding 
  2622. active call. 
  2623. .PP
  2624. The call reference provides the means to correlate FACILITY messages belonging 
  2625. to the same signalling transaction. In the case of call related 
  2626. invocations, the call reference correlates with the appropriate call
  2627. transaction. When a supplementary service affects more than one call, different 
  2628. call references are used to identify each call individually. This implies 
  2629. the use of different FACILITY messages in order to manage each call separately. 
  2630. .PP
  2631. If a call related FACILITY message is sent using the call reference of 
  2632. a call in progress or of an active call, and this call is cleared due to 
  2633. call related causes, then the call reference may not be cleared simultaneously 
  2634. in 
  2635. call cases.
  2636. .PP
  2637. Depending upon the supplementary service invoked, one of the
  2638. following will occur:
  2639. .RT
  2640. .LP
  2641.     \(em
  2642.     the network or user may retain both the connection and the
  2643. call reference association and may send a response within a
  2644. Facility information element in a FACILITY message prior to the
  2645. initiation of the normal call clearing procedures; or
  2646. .LP
  2647.     \(em
  2648.     the network or user may send a response within a Facility
  2649. information element in the first clearing message (i.e.,
  2650. DISCONNECT, RELEASE, or RELEASE COMPLETE message).
  2651. .bp
  2652. .sp 1P
  2653. .LP
  2654. 6.3.2
  2655.     \fICall independent supplementary service procedures\fR 
  2656. .sp 9p
  2657. .RT
  2658. .PP
  2659. For supplementary service procedures independent of an active call, the 
  2660. initiating side must first establish a reliable data link connection 
  2661. between the network and the user according to the data link services described 
  2662. in Recommendation\ Q.921. Once the data link connection is established 
  2663. the user or the network starts the establishment of the signalling connection 
  2664. by 
  2665. transferring a REGISTER message across the user\(hynetwork interface. This
  2666. signalling connection is identified by the call reference associated with 
  2667. the REGISTER message. The requested supplementary service is identified 
  2668. by the 
  2669. operation value within the Facility information element. This signalling
  2670. connection may be released by the exchange of return result, return error or
  2671. reject component types contained in the Facility information element within 
  2672. a RELEASE COMPLETE message. 
  2673. .PP
  2674. Examples of message exchange for supplementary service control for
  2675. various scenarios is described by means of arrow diagrams in Appendix\ I.
  2676. .PP
  2677. To assign a call reference value and convey the supplementary service invocation, 
  2678. a REGISTER message with an optional Facility information element is used. 
  2679. The Facility information element present either in the REGISTER message 
  2680. or in a subsequent message identifies the supplementary service involved 
  2681. and 
  2682. the type of operation (i.e.,\ invoke, return result, return error or reject
  2683. component). One of the following will occur:
  2684. .RT
  2685. .LP
  2686.     1)
  2687.     When the REGISTER message contains a Facility information
  2688. element and the requested service is available, a FACILITY
  2689. message containing the Facility information element may be
  2690. returned. One or more exchanges of FACILITY messages may
  2691. subsequently occur. To terminate the service interaction and
  2692. release the call reference value, a RELEASE COMPLETE message is
  2693. sent by either side of the interface. The RELEASE COMPLETE
  2694. message may also contain the Facility information element.
  2695. .LP
  2696.     2)
  2697.     If the content of the Facility information element is not
  2698. understood, then a FACILITY message or a RELEASE COMPLETE
  2699. message with the Facility information element is returned with
  2700. the Reject component type. When the rejection has been returned
  2701. in a FACILITY message, the Facility information element can be
  2702. re\(hysent in another FACILITY message or the request can be
  2703. cleared
  2704. and the call reference value released with a RELEASE COMPLETE
  2705. message.
  2706. .LP
  2707.     3)
  2708.     If the content of the Facility information element is
  2709. understood, but the supplementary service request cannot be
  2710. provided, then a FACILITY message or a RELEASE COMPLETE message
  2711. with the Facility information element is returned with the
  2712. component return error. When the rejection has been returned in
  2713. a FACILITY message, the Facility information element can be
  2714. re\(hysent in another FACILITY message or the request can be
  2715. cleared
  2716. and the call reference value released with a RELEASE COMPLETE
  2717. message.
  2718. .sp 1P
  2719. .LP
  2720. 6.3.3
  2721.     \fIResponses to multiple supplementary service invocations\fR 
  2722. .sp 9p
  2723. .RT
  2724. .PP
  2725. The possible correlation of responses to multiple supplementary
  2726. service invocations is the subject of future Recommendations.
  2727. .RT
  2728. .sp 1P
  2729. .LP
  2730. 6.3.4
  2731.     \fICoding of the call reference\fR 
  2732. .sp 9p
  2733. .RT
  2734. .PP
  2735. For general rules, format and coding of call reference values,
  2736. \(sc\ 4.3 of Recommendation Q.931 is applicable. For the functional supplementary 
  2737. service control, the dummy call reference is not applicable. 
  2738. .RT
  2739. .sp 2P
  2740. .LP
  2741. \fB7\fR     \fBMessage functional definitions and content\fR 
  2742. .sp 1P
  2743. .RT
  2744. .PP
  2745. This section should be read in conjunction with \(sc\ 3 of
  2746. Recommendation\ Q.931. All messages are additional to those defined in that
  2747. section and the following tables should be interpreted according to the
  2748. introduction of \(sc\ 3 of Recommendation\ Q.931.
  2749. .RT
  2750. .sp 1P
  2751. .LP
  2752. 7.1
  2753.     \fIMessages for supplementary service control\fR 
  2754. .sp 9p
  2755. .RT
  2756. .PP
  2757. Table\ 7\(hy1/Q.932 summarizes the messages specific to supplementary service 
  2758. control procedures. 
  2759. .bp
  2760. .RT
  2761. .ce
  2762. \fBH.T. [T3.932]\fR 
  2763. .ce
  2764. TABLE\ 7\(hy1/Q.932
  2765. .ce
  2766. \fBMessages specific to supplementary service
  2767. .ce
  2768. control\fR 
  2769. .ps 9
  2770. .vs 11
  2771. .nr VS 11
  2772. .nr PS 9
  2773. .TS
  2774. center box;
  2775. lw(90p) | cw(42p) .
  2776.     Reference 
  2777. _
  2778. .T&
  2779. lw(90p) | cw(42p) .
  2780. FACILITY    7.1.1 
  2781. .T&
  2782. lw(90p) | cw(42p) .
  2783. HOLD    7.1.2 
  2784. .T&
  2785. lw(90p) | cw(42p) .
  2786. HOLD ACKNOWLEDGE    7.1.3 
  2787. .T&
  2788. lw(90p) | cw(42p) .
  2789. HOLD REJECT    7.1.4 
  2790. .T&
  2791. lw(90p) | cw(42p) .
  2792. REGISTER    7.1.5 
  2793. .T&
  2794. lw(90p) | cw(42p) .
  2795. RETRIEVE    7.1.6 
  2796. .T&
  2797. lw(90p) | cw(42p) .
  2798. RETRIEVE ACKNOWLEDGE    7.1.7 
  2799. .T&
  2800. lw(90p) | cw(42p) .
  2801. RETRIEVE REJECT    7.1.8 
  2802. _
  2803. .TE
  2804. .nr PS 9
  2805. .RT
  2806. .ad r
  2807. \fBTable 7\(hy1/Q.932 [T3.932], p.22\fR 
  2808. .sp 1P
  2809. .RT
  2810. .ad b
  2811. .RT
  2812. .sp 1P
  2813. .LP
  2814. 7.1.1
  2815.     \fIFACILITY\fR 
  2816. .sp 9p
  2817. .RT
  2818. .PP
  2819. This message may be sent to request or acknowledge a supplementary service. 
  2820. The supplementary service to be invoked, and its associated 
  2821. parameters, are specified in the Facility information element (see
  2822. Table\ 7\(hy2/Q.932).
  2823. .PP
  2824. For the use of this message, see \(sc 6.
  2825. .RT
  2826. .ce
  2827. \fBH.T. [T4.932]\fR 
  2828. .ce
  2829. TABLE\ 7\(hy2/Q.932
  2830. .ce
  2831. \fBFACILITY message content\fR 
  2832. .ce
  2833. Message type:\ FACILITY
  2834. .ce
  2835. Significance:\ local (Note 1)
  2836. .ce
  2837. Direction:\ both
  2838. .ps 9
  2839. .vs 11
  2840. .nr VS 11
  2841. .nr PS 9
  2842. .TS
  2843. center box;
  2844. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2845. Information element    Reference    Direction     Type     Length
  2846. _
  2847. .T&
  2848. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2849. Protocol discriminator    4.2/Q.931    both    M    1 
  2850. _
  2851. .T&
  2852. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2853. Call reference    4.3/Q.931    both    M    2 | (hy |  
  2854. _
  2855. .T&
  2856. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2857. Message type    8.1/Q.932    both    M    1 
  2858. _
  2859. .T&
  2860. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2861. Facility    8.2/Q.932    both    M    8 | (hy |  
  2862. _
  2863. .T&
  2864. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2865. Display    4.5/Q.931    n \(ra |     O (Note 2)    (Note 3) 
  2866. .TE
  2867. .LP
  2868. M\ Mandatory
  2869. .LP
  2870. O\ Optional
  2871. .LP
  2872. \fINote\ 1\fR
  2873. \ \(em\ This message has local significance; however, it may carry
  2874. information of global significance.
  2875. .LP
  2876. \fINote\ 2\fR
  2877. \ \(em\ Included if the network provides information that can be
  2878. presented to the user.
  2879. .LP
  2880. \fINote\ 3\fR
  2881. \ \(em\ The minimum length is 2 octets. The maximum length is network
  2882. dependent and is either 34 or 82\ octets.
  2883. .nr PS 9
  2884. .RT
  2885. .ad r
  2886. \fBTable 7\(hy2/Q.932 [T4.932], p.23\fR 
  2887. .sp 1P
  2888. .RT
  2889. .ad b
  2890. .RT
  2891. .LP
  2892. .bp
  2893. .sp 1P
  2894. .LP
  2895. 7.1.2
  2896.     \fIHOLD\fR 
  2897. .sp 9p
  2898. .RT
  2899. .PP
  2900. This message is sent by the network or the user to request the hold function 
  2901. for an existing call (see Table\ 7\(hy3/Q.932). 
  2902. .PP
  2903. For the use of this message, see \(sc 6.
  2904. .RT
  2905. .ce
  2906. \fBH.T. [T5.932]\fR 
  2907. .ce
  2908. TABLE\ 7\(hy3/Q.932
  2909. .ce
  2910. \fBHOLD message content\fR 
  2911. .ce
  2912. Message type:\ HOLD
  2913. .ce
  2914. Significance:\ local
  2915. .ce
  2916. Direction:\ both 
  2917. .ps 9
  2918. .vs 11
  2919. .nr VS 11
  2920. .nr PS 9
  2921. .TS
  2922. center box;
  2923. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2924. Information element    Reference    Direction    Type    Length
  2925. _
  2926. .T&
  2927. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2928. Protocol discriminator    4.2/Q.931    both    M    1 
  2929. _
  2930. .T&
  2931. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2932. Call reference    4.3/Q.931    both    M    2 | (hy |  
  2933. _
  2934. .T&
  2935. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2936. Message type    8.1/Q.932    both    M    1 
  2937. _
  2938. .T&
  2939. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2940. Display    4.5/Q.931    n \(ra |     O (Note 1)    (Note 2) 
  2941. .TE
  2942. .LP
  2943. \fINote\ 1\fR
  2944. \ \(em\ Included if the network provides information that can be
  2945. presented to the user.
  2946. .LP
  2947. \fINote\ 2\fR
  2948. \ \(em\ The minimum length is 2 octets. The maximum length is
  2949. network dependent and is either 34 or 82\ octets.
  2950. .nr PS 9
  2951. .RT
  2952. .ad r
  2953. \fBTableau 7\(hy3/Q.932 [T5.932], p.24\fR 
  2954. .sp 1P
  2955. .RT
  2956. .ad b
  2957. .RT
  2958. .LP
  2959. .rs
  2960. .sp 25P
  2961. .ad r
  2962. Blanc
  2963. .ad b
  2964. .RT
  2965. .LP
  2966. .bp
  2967. .sp 1P
  2968. .LP
  2969. 7.1.3
  2970.     \fIHOLD ACKNOWLEDGE\fR 
  2971. .sp 9p
  2972. .RT
  2973. .PP
  2974. This message is sent by the network or the user to indicate that
  2975. the hold function has been successfully performed (see Table\ 7\(hy4B/FQ.932).
  2976. .PP
  2977. For the use of this message, see \(sc 6.
  2978. .RT
  2979. .ce
  2980. \fBH.T. [T6.932]\fR 
  2981. .ce
  2982. TABLE\ 7\(hy4/Q.932
  2983. .ce
  2984. \fBHOLD ACKNOWLEDGE message content\fR 
  2985. .ce
  2986. Message type:\ HOLD ACKNOWLEDGE
  2987. .ce
  2988. Significance:\ local
  2989. .ce
  2990. Direction:\ both
  2991. .ps 9
  2992. .vs 11
  2993. .nr VS 11
  2994. .nr PS 9
  2995. .TS
  2996. center box;
  2997. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  2998. Information element    Reference    Direction    Type    Length
  2999. _
  3000. .T&
  3001. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3002. Protocol discriminator    4.2/Q.931    both    M    1 
  3003. _
  3004. .T&
  3005. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3006. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3007. _
  3008. .T&
  3009. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3010. Message type    8.1/Q.932    both    M    1 
  3011. _
  3012. .T&
  3013. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3014. Display    4.5/Q.931    n \(ra |     O (Note 1)    (Note 2) 
  3015. .TE
  3016. .LP
  3017. \fINote\ 1\fR
  3018. \ \(em\ Included if the network provides information that can be
  3019. presented to the user.
  3020. .LP
  3021. \fINote\ 2\fR
  3022. \ \(em\ The minimum length is 2 octets. The maximum length
  3023. is network dependent and is either 34 or 82\ octets.
  3024. .nr PS 9
  3025. .RT
  3026. .ad r
  3027. \fBTableau 7\(hy4/Q.932 [T6.932], p.25\fR 
  3028. .sp 1P
  3029. .RT
  3030. .ad b
  3031. .RT
  3032. .LP
  3033. .rs
  3034. .sp 25P
  3035. .ad r
  3036. Blanc
  3037. .ad b
  3038. .RT
  3039. .LP
  3040. .bp
  3041. .sp 1P
  3042. .LP
  3043. 7.1.4
  3044.     \fIHOLD REJECT\fR 
  3045. .sp 9p
  3046. .RT
  3047. .PP
  3048. This message is sent by the network or the user to indicate the
  3049. denial of a request to hold a call (see Table\ 7\(hy5/Q.932).
  3050. .PP
  3051. For the use of this message, see \(sc 6.
  3052. .RT
  3053. .ce
  3054. \fBH.T. [T7.932]\fR 
  3055. .ce
  3056. TABLE\ 7\(hy5/Q.932
  3057. .ce
  3058. \fBHOLD REJECT message content\fR 
  3059. .ce
  3060. Message type:\ HOLD REJECT
  3061. .ce
  3062. Significance:\ local
  3063. .ce
  3064. Direction:\ both
  3065. .ps 9
  3066. .vs 11
  3067. .nr VS 11
  3068. .nr PS 9
  3069. .TS
  3070. center box;
  3071. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3072. Information element     Reference    Direction    Type    Length
  3073. _
  3074. .T&
  3075. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3076. Protocol discriminator    4.2/Q.931    both    M    1 
  3077. _
  3078. .T&
  3079. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3080. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3081. _
  3082. .T&
  3083. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3084. Message type    8.1/Q.932    both    M    1 
  3085. _
  3086. .T&
  3087. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3088. Cause    4.5/Q.931    both    M    4 | (hy | 2 
  3089. _
  3090. .T&
  3091. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3092. Display    4.5/Q.931    n \(ra |     O (Note 1)    (Note 2) 
  3093. .TE
  3094. .LP
  3095. \fINote\ 1\fR
  3096. \ \(em\ Included if the network provides information that can be
  3097. presented to the user.
  3098. .LP
  3099. \fINote\ 2\fR
  3100. \ \(em\ The minimum length is 2 octets. The maximum length is network
  3101. dependent and is either 34 or 82\ octets.
  3102. .nr PS 9
  3103. .RT
  3104. .ad r
  3105. \fBTableau 7\(hy5/Q.932 [T7.932], p.26\fR 
  3106. .sp 1P
  3107. .RT
  3108. .ad b
  3109. .RT
  3110. .LP
  3111. .rs
  3112. .sp 22P
  3113. .ad r
  3114. Blanc
  3115. .ad b
  3116. .RT
  3117. .LP
  3118. .bp
  3119. .sp 1P
  3120. .LP
  3121. 7.1.5
  3122.     \fIREGISTER\fR 
  3123. .sp 9p
  3124. .RT
  3125. .PP
  3126. This message is sent by the user or the network to assign a new
  3127. call reference for non\(hycall associated transactions (see Table\ 7\(hy6/Q.932). 
  3128. .PP
  3129. For the use of this message, see \(sc 6.
  3130. .RT
  3131. .ce
  3132. \fBH.T. [T8.932]\fR 
  3133. .ce
  3134. TABLE\ 7\(hy6/Q.932
  3135. .ce
  3136. \fBREGISTER message content\fR 
  3137. .ce
  3138. Message type:\ REGISTER
  3139. .ce
  3140. Significance:\ local (Note 1)
  3141. .ce
  3142. Direction:\ both
  3143. .ps 9
  3144. .vs 11
  3145. .nr VS 11
  3146. .nr PS 9
  3147. .TS
  3148. center box;
  3149. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3150. Information element     Reference    Direction    Type    Length 
  3151. _
  3152. .T&
  3153. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3154. Protocol discriminator    4.2/Q.931    both    M    1 
  3155. _
  3156. .T&
  3157. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3158. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3159. _
  3160. .T&
  3161. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3162. Message type    8.1/Q.932    both    M    1 
  3163. _
  3164. .T&
  3165. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3166. Facility    8.2/Q.932    both    O (Note 4)    2 | (hy |  
  3167. _
  3168. .T&
  3169. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3170. Display    4.5/Q.931    n \(ra |     O (Note 2)    (Note 3) 
  3171. .TE
  3172. .LP
  3173. \fINote\ 1\fR
  3174. \ \(em\ This message has local significance; however, it may carry
  3175. information of global significance.
  3176. .LP
  3177. \fINote\ 2\fR
  3178. \ \(em\ Included if the network provides information that can be
  3179. presented to the user.
  3180. .LP
  3181. \fINote\ 3\fR
  3182. \ \(em\ The minimum length is 2 octets. The maximum length is
  3183. network dependent and is either 34 or 82\ octets.
  3184. .LP
  3185. \fINote\ 4\fR
  3186. \ \(em\ Included if the network or the user provides supplementary
  3187. service information.
  3188. .nr PS 9
  3189. .RT
  3190. .ad r
  3191. \fBTableau 7\(hy6/Q.932 [T8.932], p.27\fR 
  3192. .sp 1P
  3193. .RT
  3194. .ad b
  3195. .RT
  3196. .LP
  3197. .rs
  3198. .sp 20P
  3199. .ad r
  3200. Blanc
  3201. .ad b
  3202. .RT
  3203. .LP
  3204. .bp
  3205. .sp 1P
  3206. .LP
  3207. 7.1.6
  3208.     \fIRETRIEVE\fR 
  3209. .sp 9p
  3210. .RT
  3211. .PP
  3212. This message is sent by the network or the user to request the
  3213. retrieval of a held call (see Table\ 7\(hy7/Q.932).
  3214. .PP
  3215. For the use of this message, see \(sc 6.
  3216. .RT
  3217. .ce
  3218. \fBH.T. [T9.932]\fR 
  3219. .ce
  3220. TABLE\ 7\(hy7/Q.932
  3221. .ce
  3222. \fBRETRIEVE message content\fR 
  3223. .ce
  3224. Message type:\ RETRIEVE
  3225. .ce
  3226. Significance:\ local
  3227. .ce
  3228. Direction:\ both
  3229. .ps 9
  3230. .vs 11
  3231. .nr VS 11
  3232. .nr PS 9
  3233. .TS
  3234. center box;
  3235. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3236. Information element    Reference    Direction    Type    Length
  3237. _
  3238. .T&
  3239. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3240. Protocol discriminator    4.2/Q.931    both    M    1 
  3241. _
  3242. .T&
  3243. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3244. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3245. _
  3246. .T&
  3247. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3248. Message type    8.1/Q.932    both    M    1 
  3249. _
  3250. .T&
  3251. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3252. Channel identification    4.5/Q.931    both    O (Note 1)    2 | (hy |  
  3253. _
  3254. .T&
  3255. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3256. Display    4.5/Q.931    n \(ra |     O (Note 2)    (Note 3) 
  3257. .TE
  3258. .LP
  3259. \fINote\ 1\fR
  3260. \ \(em\ If not included, its absence is interpreted as any channel
  3261. acceptable.
  3262. .LP
  3263. \fINote\ 2\fR
  3264. \ \(em\ Included if the network provides information that can be
  3265. presented to the user.
  3266. .LP
  3267. \fINote\ 3\fR
  3268. \ \(em\ The minimum length is 2 octets. The maximum length
  3269. is network dependent and is either 34 or 82 octets.
  3270. .nr PS 9
  3271. .RT
  3272. .ad r
  3273. \fBTableau 7\(hy7/Q.932 [T9.932], p.28\fR 
  3274. .sp 1P
  3275. .RT
  3276. .ad b
  3277. .RT
  3278. .LP
  3279. .rs
  3280. .sp 21P
  3281. .ad r
  3282. Blanc
  3283. .ad b
  3284. .RT
  3285. .LP
  3286. .bp
  3287. .sp 1P
  3288. .LP
  3289. 7.1.7
  3290.     \fIRETRIEVE ACKNOWLEDGE\fR 
  3291. .sp 9p
  3292. .RT
  3293. .PP
  3294. This message is sent by the network or the user to indicate that
  3295. the retrieve function has been successfully performed (see
  3296. Table\ 7\(hy8/Q.932).
  3297. .PP
  3298. For the use of this message, see \(sc 6.
  3299. .RT
  3300. .ce
  3301. \fBH.T. [T10.932]\fR 
  3302. .ce
  3303. TABLE\ 7\(hy8/Q.932
  3304. .ce
  3305. \fBRETRIEVE ACKNOWLEDGE message content\fR 
  3306. .ce
  3307. Message type:\ RETRIEVE ACKNOWLEDGE
  3308. .ce
  3309. Significance:\ local
  3310. .ce
  3311. Direction:\ both
  3312. .ps 9
  3313. .vs 11
  3314. .nr VS 11
  3315. .nr PS 9
  3316. .TS
  3317. center box;
  3318. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3319. Information element     Reference    Direction    Type    Length
  3320. _
  3321. .T&
  3322. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3323. Protocol discriminator    4.2/Q.931    both    M    1 
  3324. _
  3325. .T&
  3326. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3327. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3328. _
  3329. .T&
  3330. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3331. Message type    8.1/Q.932    both    M    1 
  3332. _
  3333. .T&
  3334. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3335. Channel identification    4.5/Q.931    both    O (Note 1)    2 | (hy |  
  3336. _
  3337. .T&
  3338. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3339. Display    4.5/Q.931    n \(ra |     O (Note 2)    (Note 3) 
  3340. .TE
  3341. .LP
  3342. \fINote\ 1\fR
  3343. \ \(em\ Mandatory in all cases except when the sender accepts the
  3344. specific B\(hychannel indicated in the RETRIEVE message. If included, a channel
  3345. is indicated and specified as exclusive.
  3346. .LP
  3347. \fINote\ 2\fR
  3348. \ \(em\ Included if the network provides information that can be
  3349. presented to the user.
  3350. .LP
  3351. \fINote\ 3\fR
  3352. \ \(em\ The minimum length is 2 octets. The maximum length
  3353. is network dependent and is either 34 or 82\ octets.
  3354. .nr PS 9
  3355. .RT
  3356. .ad r
  3357. \fBTableau 7\(hy8/Q.932 [T10.932], p.29\fR 
  3358. .sp 1P
  3359. .RT
  3360. .ad b
  3361. .RT
  3362. .LP
  3363. .rs
  3364. .sp 20P
  3365. .ad r
  3366. Blanc
  3367. .ad b
  3368. .RT
  3369. .LP
  3370. .bp
  3371. .sp 1P
  3372. .LP
  3373. 7.1.8
  3374.     \fIRETRIEVE REJECT\fR 
  3375. .sp 9p
  3376. .RT
  3377. .PP
  3378. This message is sent by the network or the user to indicate the
  3379. inability to perform the requested retrieve function (see Table\ 7\(hy9/Q.932).
  3380. .PP
  3381. For the use of this message, see \(sc 6.
  3382. .RT
  3383. .ce
  3384. \fBH.T. [T11.932]\fR 
  3385. .ce
  3386. TABLE\ 7\(hy9/Q.932
  3387. .ce
  3388. \fBRETRIEVE REJECT message content\fR 
  3389. .ce
  3390. Message type:\ RETRIEVE REJECT
  3391. .ce
  3392. Significance:\ local
  3393. .ce
  3394. Direction:\ both 
  3395. .ps 9
  3396. .vs 11
  3397. .nr VS 11
  3398. .nr PS 9
  3399. .TS
  3400. center box;
  3401. cw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3402. Information element     Reference    Direction    Type    Length
  3403. _
  3404. .T&
  3405. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3406. Protocol discriminator    4.2/Q.931    both    M    1 
  3407. _
  3408. .T&
  3409. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3410. Call reference    4.3/Q.931    both    M    2 | (hy |  
  3411. _
  3412. .T&
  3413. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3414. Message type    8.1/Q.932    both    M    1 
  3415. _
  3416. .T&
  3417. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3418. Cause    4.5/Q.931    both    M    4 | (hy | 2 
  3419. _
  3420. .T&
  3421. lw(84p) | cw(30p) | cw(42p) | cw(42p) | cw(30p) .
  3422. Display    4.5/Q.931    n \(ra |     O (Note 1)    (Note 2) 
  3423. .TE
  3424. .LP
  3425. \fINote\ 1\fR
  3426. \ \(em\ Included if the network provides information that can be
  3427. presented to the user.
  3428. .LP
  3429. \fINote\ 2\fR
  3430. \ \(em\ The minimum length is 2 octets. The maximum length is network
  3431. dependent and is either 34 or 82 octets.
  3432. .nr PS 9
  3433. .RT
  3434. .ad r
  3435. \fBTableau 7\(hy9/Q.932 [T11.932], p.30\fR 
  3436. .sp 1P
  3437. .RT
  3438. .ad b
  3439. .RT
  3440. .LP
  3441. .rs
  3442. .sp 22P
  3443. .ad r
  3444. Blanc
  3445. .ad b
  3446. .RT
  3447. .LP
  3448. .bp
  3449.